linux-kernel - Re: [RFC][PATCH 2/2] shmem: fix recovery on rename failures

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: <20251215165421.GN1712166@ZenIV>
Date: Mon, 15 Dec 2025 16:54:21 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Chuck Lever <chuck.lever@...cle.com>
Cc: Hugh Dickins <hughd@...gle.com>, Miklos Szeredi <miklos@...redi.hu>,
	Christian Brauner <brauner@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Baolin Wang <baolin.wang@...ux.alibaba.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC][PATCH 2/2] shmem: fix recovery on rename failures

On Mon, Dec 15, 2025 at 11:03:58AM -0500, Chuck Lever wrote:
> > @@ -388,31 +388,23 @@ int simple_offset_rename_exchange(struct inode *old_dir,
> >  	long new_index = dentry2offset(new_dentry);
> >  	int ret;
> >  
> > -	simple_offset_remove(old_ctx, old_dentry);
> > -	simple_offset_remove(new_ctx, new_dentry);
> > +	if (WARN_ON(!old_index || !new_index))
> > +		return -EINVAL;
> >  
> > -	ret = simple_offset_replace(new_ctx, old_dentry, new_index);
> > -	if (ret)
> > -		goto out_restore;
> > +	ret = mtree_store(&new_ctx->mt, new_index, old_dentry, GFP_KERNEL);
> > +	if (WARN_ON(ret))
> > +		return ret;
> >  
> > -	ret = simple_offset_replace(old_ctx, new_dentry, old_index);
> > -	if (ret) {
> > -		simple_offset_remove(new_ctx, old_dentry);
> > -		goto out_restore;
> > +	ret = mtree_store(&old_ctx->mt, old_index, new_dentry, GFP_KERNEL);
> > +	if (WARN_ON(ret)) {
> > +		mtree_store(&new_ctx->mt, new_index, new_dentry, GFP_KERNEL);
> 
> Under extreme memory pressure, this mtree_store() might also fail?

Neither should, really; adding after entry removal, as the mainline
does, might need allocations.  But mtree_store() when entry exists
and isn't a part of a range should not allocate anything.

What happens is that mas_wr_store_type() will return wr_exact_fit to
mas_wr_preallocate(), which will shove it into ->store_type before
calling mas_prealloc_calc(), getting ->node_request set to 0 by the
latter, seeing that and buggering off without allocating anything.

So these WARN_ON() are of the "if it triggers, something's really wrong -
either lib/maple_tree.c had an odd change of behaviour, or we have
our tree in unexpected state" variety, not "warn that operation's
failing due to OOM" one.