Re: [PATCH 0/11] Per-bdi writeback flusher threads v8
From: Theodore Tso
Date: Thu May 28 2009 - 15:33:25 EST
On Thu, May 28, 2009 at 08:23:28AM -0700, Eric W. Biederman wrote:
> I thought the network stack was the only piece of code silly enough
> to hold locks while deleting sysfs files.
> Holding any lock while deleting a objects from sysfs, sysctl or proc,
> is asking for serious mischief, and unfixable from the fs side.
> The usual problem is that lockdep doesn't yet understand
> sysfs_deactivate which waits for any running sysfs operations to
> complete before it deletes the sysfs files.
> Which means any lock you hold in a show or store method is can deadlock
> with any lock you hold while deleting from sysfs.
> ext4 appears lock loose and fancy free in it's show and store methods
> so it might be ok except for this issue of mmap_sem vs sysfs_mutex.
> But apparently even that isn't enough to git rid of the requirement
> to not hold locks when deleting objects.
I ran into this problem, and I attempted to work around the fact that
the core VFS layer calls the fs's put_super() while holding the BKL
and the super block lock as follows at the very end of ext4's
* Now that we are completely done shutting down the
* superblock, we need to actually destroy the kobject.
I'm pretty sure that after the first call to invalidate_inodes() in
fs/super.c's generic_shutdown_super(), we really don't need to hold
the BKL or the superblock lock (and let the filesystems' low-level
write_super(0 and put_super() take the lock if they really need it),
but we probably need to take a closer look at this to make sure it's
true for all filesystems. (IIRC, I think Christoph was looking to
clean up lock_super(); at least with respect to the write_super call.
I don't know what his plans regarding the BKL and put_super(),
Fundamentally, right now it's rather painful to use sysfs from within
a filesystem driver, since the generic VFS layer doesn't have any
explicit kobject support functionality.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/