linux-kernel - Re: [patch 19/35] fs: icache remove redundant i_sb

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]

Date:	Wed, 20 Oct 2010 13:46:31 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	npiggin@...nel.dk
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [patch 19/35] fs: icache remove redundant i_sb_list umount
 locking

On Tue, Oct 19, 2010 at 02:42:35PM +1100, npiggin@...nel.dk wrote:
> +	/*
> +	 * We can walk the per-sb list of inodes here without worrying about
> +	 * its consistency, because the list must not change during umount
> +	 * anymore, and because iprune_sem keeps shrink_icache_memory() away.
> +	 */
>  	fsnotify_unmount_inodes(&sb->s_inodes);

OK, explain to me why is that safe.  Note that fsnotify_destroy_mark()
_can_ race with umount, dropping the last reference to inode before
fsnotify_unmount_inodes() would get to it and kill it (along with the mark).
With the current code it's just fine - we walk the list under lock and
iput() won't mess with that list until it acquires the damn lock.  And
no matter who gets there first, the mark will be destroyed and reference
to inode will be dropped.

With your change, AFAICS, removal from the list can happen while we walk
it.  With obvious results.
--
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/