linux-kernel - Re: [RFC PATCH 19/24] erofs: introduce namei alternative to C

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: <20240917073149.GD3107530@ZenIV>
Date: Tue, 17 Sep 2024 08:31:49 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Gao Xiang <hsiangkao@...ux.alibaba.com>
Cc: Yiyang Wu <toolmanp@...p.cc>, linux-erofs@...ts.ozlabs.org,
	rust-for-linux@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 19/24] erofs: introduce namei alternative to C

On Tue, Sep 17, 2024 at 03:14:58PM +0800, Gao Xiang wrote:

> > Sorry for my ignorance.
> > I mean i just borrowed the code from the fs/erofs/namei.c and i directly
> > translated that into Rust code. That might be a problem that also
> > exists in original working C code.
> 
> As for EROFS (an immutable fs), I think after d_splice_alias(), d_name is
> still stable (since we don't have rename semantics likewise for now).

Even on corrupted images?  If you have two directories with entries that
act as hardlinks to the same subdirectory, and keep hitting them on lookups,
it will have to transplant the subtree between the parents.

> But as the generic filesystem POV, d_name access is actually tricky under
> RCU walk path indeed.

->lookup() is never called in RCU mode.

> > That's kinda interesting, I originally thought that VFS will make sure
> > its d_name / d_parent is stable in the first place.
> > Again, I just don't have a full picture or understanding of VFS and my
> > code is just basic translation of original C code, Maybe we can address
> > this later.
> 
> d_alloc will allocate an unhashed dentry which is almost unrecognized
> by VFS dcache (d_name is stable of course).
> 
> After d_splice_alias() and d_add(), rename() could change d_name.  So
> either we take d_lock or with rcu_read_lock() to take a snapshot of
> d_name in the RCU walk path.  That is my overall understanding.

No, it's more complicated than that, sadly.  ->d_name and ->d_parent are
the trickiest parts of dentry field stability.

> But for EROFS, since we don't have rename, so it doesn't matter.

See above.  IF we could guarantee that all filesystem images are valid
and will remain so, life would be much simpler.