linux-kernel - Re: [RESEND PATCH v7 7/8] kernfs: Replace per-fs rwsem with hashed rwsems.

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: <YjgpaeFfFandY999@zeniv-ca.linux.org.uk>
Date:   Mon, 21 Mar 2022 07:29:45 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Imran Khan <imran.f.khan@...cle.com>
Cc:     tj@...nel.org, gregkh@...uxfoundation.org,
        akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH v7 7/8] kernfs: Replace per-fs rwsem with hashed
 rwsems.

On Mon, Mar 21, 2022 at 12:57:07PM +1100, Imran Khan wrote:

> Yes. My earlier approach is wrong.
> 
> This patch set has also introduced a per-fs mutex (kernfs_rm_mutex)
> which should fix the problem of inconsistent tree view as far as
> kernfs_get_path is concerned.
> Acquiring kernfs_rm_mutex before invoking kernfs_get_path in
> kernfs_getlink will ensure that kernfs_get_path will get a consistent
> view of ->parent of nodes from root to target. This is because acquiring
> kernfs_rm_mutex will ensure that __kernfs_remove does not remove any
> kernfs_node(or parent of kernfs_node). Further it ensures that
> kernfs_rename_ns does not move any kernfs_node. So far I have not used
> per-fs mutex in kernfs_rename_ns but I can make this change in next
> version. So following change on top of current patch set should fix
> this issue of ->parent change in the middle of kernfs_get_path.

I think it's a massive overkill.  Look at kernfs_get_target_path() -
nothing in it is blocking.  And you already have kernfs_rename_lock,
stabilizing the tree topology.  Turn it into rwlock if you wish,
with that thing being a reader and existing users - writers.
And don't bother with further scaling, until and unless you see a real
contention on it.