linux-kernel - Re: [PATCH 30/30] VFS: Destroy the dentries contributed by a superblock on unmounting [try #11]

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:	Tue, 01 Aug 2006 11:18:05 +0100
From:	David Howells <dhowells@...hat.com>
To:	Jan Blunck <j.blunck@...harburg.de>
Cc:	David Howells <dhowells@...hat.com>, torvalds@...l.org,
	akpm@...l.org, steved@...hat.com, trond.myklebust@....uio.no,
	linux-fsdevel@...r.kernel.org, linux-cachefs@...hat.com,
	nfsv4@...ux-nfs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 30/30] VFS: Destroy the dentries contributed by a superblock on unmounting [try #11] 

Jan Blunck <j.blunck@...harburg.de> wrote:

> IMHO it is better to fix shrink_dcache_for_umount() so that it is a
> replacement for shrink_dcache_sb().

The former may only be used when we *know* there aren't any references
remaining to any of the dentries (as it severely reduces the amount of time
spent holding the dcache_lock).  The latter is used in situations in which the
assumptions of the former don't hold true.

Now I could make the former hold the locking a lot more (I had a version of
the patch that did that), but the former destroys all an sb's dentries,
whether or not they're still in use (which they shouldn't be), and the latter
does not.

The latter also doesn't reap the anon list directly; only where anon dentries
are also unused does any anon reaping occur.  The former reaps them directly
and forcibly.

So, in conclusion, I don't think you can replace the latter with the former,
and the latter is insufficiently complete to replace the former.

> BTW: Talking about shrink_dcache_sb(): is it really necessary to call
> shrink_dcache_sb() when remounting a filesystem? The only reason I can see
> are changes to the lookup mechanism (hash algorithm etc) but a quick look
> into the different filesystems forbid the change of this options during
> remount.

If you're just remounting, then not all dentries can necessarily be purged
anyway - some of them may still be open.  Consider remounting root for
read-only or read-write...

David
-
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/