linux-kernel - Re: [PATCH 0/11] Per-bdi writeback flusher threads v8

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090528193246.GX26625@mit.edu>
Date:	Thu, 28 May 2009 15:32:46 -0400
From:	Theodore Tso <tytso@....edu>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Jan Kara <jack@...e.cz>, Jens Axboe <jens.axboe@...cle.com>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	chris.mason@...cle.com, david@...morbit.com, hch@...radead.org,
	akpm@...ux-foundation.org, yanmin_zhang@...ux.intel.com,
	richard@....demon.co.uk, damien.wyart@...e.fr,
	Alex Chiang <achiang@...com>,
	"Eric W. Biederman" <ebiederm@...stanetworks.com>
Subject: Re: [PATCH 0/11] Per-bdi writeback flusher threads v8

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
put_super() function:

	/*
	 * Now that we are completely done shutting down the
	 * superblock, we need to actually destroy the kobject.
	 */
	unlock_kernel();
	unlock_super(sb);
	kobject_put(&sbi->s_kobj);
	wait_for_completion(&sbi->s_kobj_unregister);
	lock_super(sb);
	lock_kernel();

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(),
though.)

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.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/