On Fri, Dec 22, 2023 at 2:44 PM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > If I do that, would you preffer to take these patches via the vfs tree > > I would prefer if you: > > * Add the vfs infrastructure stuff on top of what's in vfs.file. > There's also currently a conflict between this series and what's in there. I did not notice any actual conflicts with vfs.file. They do change the same files, but nothing that git can't handle. Specifically, FMODE_BACKING was excepted from the fput() changes, so also no logic changes that I noticed. The only conflict I know of is with the vfs.rw branch, the move of *_start_write() into *__iter_write(), therefore, these patches are already based on top of vfs.rw. I've just pushed branch backing_file rebased over both vfs.rw and vfs.file to: https://github.com/amir73il/linux/commits/backing_file Started to run overlayfs tests to see if vfs.file has unforeseen impact that I missed in review. > * Pull vfs.file into overlayfs. > * Port overlayfs to the new infrastructure. > Wait, do you mean add the backing_file_*() helpers and only then convert overlayfs to use them? I think that would be harder to review (also in retrospect) so the "factor out ... helper" patches that move code from overlayfs to fs/backing_file.c are easier to follow. Or did you mean something else? > io_uring already depends on vfs.file as well. > > If this is straightforward I can include it in v6.8. The VFS prs will go > out the week before January 7. Well, unless I misunderstood you, that was straightforward. The only complexity is the order and dependency among the PRs. If I am not mistaken, backing_file could be applied directly on top of vfs.rw and sent right after it, or along with it (via your tree)? If I am not mistaken, backing_file is independent of vfs.file, but surely it could be sent after vfs.file. The changes I currently have in overlayfs-next for 6.8 are very mild and do not conflict with any of the aforementioned work. If you prefer that I send the PR for backing_file via overlayfs tree, I can do that, even in the second part of the merge window, after vfs.file and vfs.rw are merged, but in that case, I would like to be able to treat vfs.rw and stable from here on, so that I can pull it into overlayfs-next and put backing_file to soak in linux-next. Let me know how you want to deal with that. Thanks, Amir.