On 2024/2/22 7:51, Kent Overstreet wrote:
On Wed, Feb 21, 2024 at 08:36:58AM -0500, Brian Foster wrote:
On Wed, Feb 21, 2024 at 05:37:04PM +0800, Hongbo Li wrote:
For mount option with bool type, the value must be 0 or 1 (See
bch2_opt_parse). But this seems does not well intercepted cause
for other value(like 2...), it returns the unexpect return code
with error message printed.
Signed-off-by: Hongbo Li <[email protected]>
---
fs/bcachefs/opts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/bcachefs/opts.c b/fs/bcachefs/opts.c
index b1ed0b9a20d3..fe1f17830694 100644
--- a/fs/bcachefs/opts.c
+++ b/fs/bcachefs/opts.c
@@ -314,7 +314,7 @@ int bch2_opt_parse(struct bch_fs *c,
if (ret < 0 || (*res != 0 && *res != 1)) {
if (err)
prt_printf(err, "%s: must be bool",
opt->attr.name);
- return ret;
+ return ret < 0 ?: -EINVAL;
It might be nice for that error message to be more specific in that the
bool value must be 0 or 1, but LGTM regardless:
Please give this a distinct private error code as well (just like we
discussed in the previous patch)
Here, the -EINVAL refers to the return value of other exception branches
of this function to keep the consistent error code of this function.
In fact, it is a bit confusing to use whether to return a private error
code or a system error code in some functions. For example, in
bch2_opt_validate, the two exception branches of no sector alignment and
power of 2 do not return internal error codes.
I don't know what the boundaries are for using private error codes.
Generally, internal functions are passed through private error codes,
but now I can only refer to this function context to determine the error
code type.
Reviewed-by: Brian Foster <[email protected]>
}
break;
case BCH_OPT_UINT:
--
2.34.1
