On 12/23/24 11:28 AM, Liam R. Howlett wrote:
* 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?
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@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
--
Chuck Lever
