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

[Al Viro <viro@zeniv.linux.org.uk>]

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.