sysfs_readdir() starts with doing
ns = sysfs_info(dentry->d_sb)->ns[type];
then proceeds to scan the directory with sysfs_dir_{,next_}pos(ns, ...)
even though we have no promise whatsoever that sysfs_exit_ns() has not
cleared that element of array in the meanwhile.
Granted, sysfs_dir_pos() doesn't dereference ns; however, it does compare
with it. And ns might have been freed and reused by that point.
I don't like what's going on there; that code looks inherently racy.
We never set ->ns[...] non-NULL outside of mount(). So it looks like
the intended behaviour is to have all ns-specific entries of that type
disappear forever from that fs instance. Having entries for _another_
namespace to show up for a (short) while, and that only in readdir()
(lookup runs completely under sysfs_mutex, so we don't have that race
there)...
I also don't like the s_instances abuse in sysfs_exit_ns() but I'd like
to understand what is that code *for* before starting to massage it into
something saner. What are the possible locking conditions in callers of
that thing? I've tried to look for callers, but the (too long) callchain
has led me to pernet_operations ->exit() and at that point I'd given up -
that over the top for grepping...
BTW, is kobj_ns_current() pinned down? Can that ns disappear from under
sysfs_mount()? It looks like it shouldn't, but then I haven't traced the
callers of sysfs_exit_ns()...
What I'm planning to do (for unrelated reasons - ubifs needs it) is to add
an analog of iterate_supers() that would go over the superblocks of given
type and call a function on them. I would like to convert sysfs_exit_ns()
to it and kill the last abuser of s_instances (and one of the last sb_lock
ones), but that really depends on what kind of locking is needed for
readdir() and friends - as it is, the damn thing looks *wrong*.
--
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
