* cel@xxxxxxxxxx <cel@xxxxxxxxxx> [241220 10:33]:
> From: Chuck Lever <chuck.lever@xxxxxxxxxx>
>
> Testing shows that the EBUSY error return from mtree_alloc_cyclic()
> leaks into user space. The ERRORS section of "man creat(2)" says:
>
> > EBUSY O_EXCL was specified in flags and pathname refers
> > to a block device that is in use by the system
> > (e.g., it is mounted).
>
> ENOSPC is closer to what applications expect in this situation.
Should the tree be returning ENOSPC in this case as apposed to
translating it here?
>
> Note that the normal range of simple directory offset values is
> 2..2^63, so hitting this error is going to be rare to impossible.
>
> Fixes: 6faddda69f62 ("libfs: Add directory operations for stable offsets")
> Cc: <stable@xxxxxxxxxxxxxxx> # v6.9+
> Reviewed-by: Jeff Layton <jlayton@xxxxxxxxxx>
> Reviewed-by: Yang Erkun <yangerkun@xxxxxxxxxx>
> Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx>
> ---
> fs/libfs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/libfs.c b/fs/libfs.c
> index 748ac5923154..3da58a92f48f 100644
> --- a/fs/libfs.c
> +++ b/fs/libfs.c
> @@ -292,8 +292,8 @@ int simple_offset_add(struct offset_ctx *octx, struct dentry *dentry)
>
> ret = mtree_alloc_cyclic(&octx->mt, &offset, dentry, DIR_OFFSET_MIN,
> LONG_MAX, &octx->next_offset, GFP_KERNEL);
> - if (ret < 0)
> - return ret;
> + if (unlikely(ret < 0))
> + return ret == -EBUSY ? -ENOSPC : ret;
>
> offset_set(dentry, offset);
> return 0;
> --
> 2.47.0
>
>
