On Mon, 14 Aug 2023, Snaipe wrote: > > Your sending this patch does help to raise the priority for my > > sending that patch: thank you; but I cannot promise when that will be. > > Hey Hugh, > > Just as an additional data point, if it helps with priority :) > > The lack of support of user xattrs on tmpfs our last remaining blocker for > using unprivileged overlayfs mounts that use a tmpfs for the upper dir & work > dir. Not that it isn't possible to use unprivileged overlayfs mounts in general, > but not having this option means that use-cases for discardable upper layer > changes are harder to clean up correctly when not on an tmpfs mount whose > lifetime is bound to a mount namespace. > > I don't think there's any rush; we can live with rmdir failing with EIO for now, > but it'd be great to see this fixed rather than having to implement expensive > cleanup routines that have to remove the upper+work dirs recursively with > CAP_DAC_OVERRIDE. Thanks for the encouragement. At the time that I wrote that (20 July) I did not expect to get around to it for months. But there happens to have been various VFS-involving works going on in mm/shmem.c recently, targeting v6.6: which caused me to rearrange priorities, and join the party with tmpfs user xattrs, see https://lore.kernel.org/linux-fsdevel/e92a4d33-f97-7c84-95ad-4fed8e84608c@xxxxxxxxxx/ Which Christian Brauner quickly put into his vfs.git (vfs.tmpfs branch): so unless something goes horribly wrong, you can expect them in v6.6. There's a lot that you wrote above which I have no understanding of whatsoever (why would user xattrs stop rmdir failing?? it's okay, don't try to educate me, I don't need to know, I'm just glad if they help you). Though your mention of "unprivileged" does make me shiver a little: Christian will understand the implications when I do not, but I wonder if my effort to limit the memory usage of user xattrs to "inode space" can be be undermined by unprivileged mounts with unlimited (or default, that's bad enough) nr_inodes. If so, that won't endanger the tmpfs user xattrs implementation, since the problem would already go beyond those: can an unprivileged mount of tmpfs allow its user to gobble up much more memory than is good for the rest of the system? Hugh
