On 12/23/24 11:28 AM, Liam R. Howlett wrote:
- cel@kernel.org cel@kernel.org [241220 10:33]:
From: Chuck Lever chuck.lever@oracle.com
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?
ENOSPC means "No space left on device." which has a certain filesystem-like ring to it. So translation in a filesystem caller seems sensible to me.
If you change mtree_alloc_cyclic() wouldn't you also need to update other mtree and xarray APIs as well, for consistency? That could be a lot of bother.
But if you'd like to change the mtree API, I won't argue. It's not a crazy idea.
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@vger.kernel.org # v6.9+ Reviewed-by: Jeff Layton jlayton@kernel.org Reviewed-by: Yang Erkun yangerkun@huawei.com Signed-off-by: Chuck Lever chuck.lever@oracle.com
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