On Thu, Aug 1, 2019 at 6:09 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Thu, Aug 01, 2019 at 04:02:39PM +0200, Ondrej Mosnacek wrote: > > After hours and hours of getting familiar with dcache and debugging, > > I think I finally found a solution that works and hopefully stands a > > chance of being committed. > > > > The series still doesn't address the lack of atomicity of the policy > > reload transition, but this is part of a wider problem and can be > > resolved later. Let's fix at least the userspace-triggered lockup > > first. > > I don't think this is the right approach. Consider the related problem: > what happens if somebody has mounted something upon a selinuxfs file? > That is the hard part here, and AFAICS your variant doesn't help it > at all... But that's another independent problem and it's not even fixed in debugfs, which for now I'm treating as the baseline as I don't know of any other filesystem that needs to remove its own directory trees in a similar way. I get that you don't want me to add a new function to the dcache API that isn't bulletproof (and what I wrote here is apparently still far from it), but you also previously said that I shouldn't open-code this stuff in selinuxfs.c... I don't think I have the wits to write a common function that handles all the possible issues, but I still want to fix at least this one scenario (dcache_readdir() vs. sel_remove_entries()). Is there some way I could do this without getting a NACK from you? For example, I thought of taking what is now debugfs_remove[_recursive]() out of debugfs into, say, fs/libfs.c (providing some optional callback to allow debugfs to do its __debugfs_file_removed() business) and use this function(s) from both debugfs and selinuxfs. This way we could later fix the leftover mount issue in one place and both filesystems would (hopefully) immediately benefit from it. Would that be a feasible way forward? Thanks, -- Ondrej Mosnacek <omosnace at redhat dot com> Software Engineer, Security Technologies Red Hat, Inc.
