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  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 Nov 2017 23:19:52 +0000
From:   Al Viro <>
To:     NeilBrown <>
Cc:     Linus Torvalds <>,
        linux-fsdevel <>,
        Linux Kernel Mailing List <>
Subject: Re: [PATCH 2/3] Improve fairness when locking the per-superblock
 s_anon list

On Fri, Nov 10, 2017 at 10:09:09AM +1100, NeilBrown wrote:

> So if an NFS server is getting lots of read/write request without opens
> or other pathname lookups, it could easily have lots of disconnected
> files being repeatedly accessed.  Keeping the dentries on d_anon means
> we don't need to keep allocating new ones for every request.
> So I'm not keen on dropping an IS_ROOT() dentry at final dput(), but
> it might make sense to add the dentry to the per-fs list of IS_ROOT
> dentries at that time.

Watch out for dput() fast path (see fast_dput()) if you go that way.

> One possible approach would be to use d_child rather than d_hash to link
> together dentries that don't have a parent.
> We could assign a random number to d_name.hash so it could appear to be
> hashed without imposing on any one hash chain.  We would still need a
> spinlock in the superblock to manage the d_anon list that links the
> d_child's together...
> I might try to see how the code looks.

Keep in mind that d_hash() includes bits of ->d_parent, aka. dentry itself.
So no need for fake ->d_name.hash; you'll get spread from that part.

->d_child is... delicate.  There are very interesting games around d_walk
vs. dput already; I'd be very careful with that one.

Powered by blists - more mailing lists