linux-kernel - Re: [PATCH 01/46] Revert "fs: use RCU read side protection in d

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:	Thu, 9 Dec 2010 16:16:17 +1100
From:	Nick Piggin <npiggin@...nel.dk>
To:	Nick Piggin <npiggin@...nel.dk>
Cc:	Dave Chinner <david@...morbit.com>, Nick Piggin <npiggin@...e.de>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/46] Revert "fs: use RCU read side protection in
   d_validate"

On Thu, Dec 09, 2010 at 03:38:42PM +1100, Nick Piggin wrote:
> > Code changes. It may not be doing what it was originally
> > needed/intended to be doing - I don't need to waste time on code
> > archeology and second guessing when there are others around that can
> > tell me this off the top oftheir head. ;)
> 
> Well the d_validate API is meant to provide that, so it's broken
> whether or not its callers use it correctly. It's also exported
> to external modules...
> 
> Yes we should remove smbfs and rip the cache out of ncpfs and
> remove d_validate entirely when possible (or, provide a more

The reason why I don't remove the caching crap entirely is because
it is not a trivial change to properly remove it, and I don't have
the time or inclination to do it properly and have it tested when
it's easy to provide a correct, simple, and back compatible API.

The patch Christoph posted for smbfs and ncpfs just hacks out where the
dentry is used from the cache, but leaves a lot of cache infrastructure
there to rot.

> reasonable API and caching library entirely in the dcache code
> that a filesystem might use). But this is the right first step.

For the record, if anyone cares, the sanest and simplest way to do this
would be to store the dentry's hash along with its pointer, and have
interfaces to allocate, destroy, insert, and delete from cache, and
lookup based on a supplied compare function. (but obviously we shouldn't
bother unless some good numbers turn up)

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