ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes: > >> On Sat, Apr 12, 2014 at 03:15:39PM -0700, Eric W. Biederman wrote: >> >>> Can you explain which scenario you are thinking about with respect to a >>> failed modprobe? >> >> Again, it's not impossible to audit (there's not a lot of places where >> struct file_system_type * is ever stored, there are few instances of >> struct file_system_type, all statically allocated, etc.), but it's >> a non-trivial amount of work. And I honestly don't know if we have >> any such places right now. Moreover, unless you feel like repeating >> that kind of audit every merge window, we'll need a some way of dealing >> with such situations. Something like flush_pending_mntput(fs_type), for >> example, documented as barrier to be used in such places might do, but >> if you can think of something more fool-proof... > > I performed a quick audit and I don't see that case happening in the > current code. Sigh. I was wrong. Almost this exact case happens in btrfs_init_test_fs, and of course I was silly when I thought the module ref count would be useful for something before init_module succeeds. Still I suspect I was on the right track. We do have the get_fs_type, get_filesystem and put_filesystem. Which ought to be enough to allow us to convert unregister_filesystem into an appropriate barrier. Something to look at after I have slept. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
