Re: [RFC][PATCH 0/4] Intruduce stacking filesystem vfs helpers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux