| Message ID | 20221130132156.2836184-3-linan122@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | iocost bugfix | expand |
On Wed, Nov 30, 2022 at 09:21:49PM +0800, Li Nan wrote: > From: Yu Kuai <yukuai3@huawei.com> > > 1) There are one place that return value of match_u64() is not checked. > 2) If match_u64() failed, return value is set to -EINVAL despite that > there are other possible errnos. Ditto. Does this matter?
Hi, 在 2022/12/01 4:32, Tejun Heo 写道: > On Wed, Nov 30, 2022 at 09:21:49PM +0800, Li Nan wrote: >> From: Yu Kuai <yukuai3@huawei.com> >> >> 1) There are one place that return value of match_u64() is not checked. >> 2) If match_u64() failed, return value is set to -EINVAL despite that >> there are other possible errnos. > > Ditto. Does this matter? > It's not a big deal, but I think at least return value of match_u64() should be checked, we don't want to continue with invalid input, right? By the way, match_u64() can return -ERANGE, which can provide more specific error messge to user. Thanks, Kuai
On Thu, Dec 01, 2022 at 10:15:53AM +0800, Yu Kuai wrote: > Hi, > > 在 2022/12/01 4:32, Tejun Heo 写道: > > On Wed, Nov 30, 2022 at 09:21:49PM +0800, Li Nan wrote: > > > From: Yu Kuai <yukuai3@huawei.com> > > > > > > 1) There are one place that return value of match_u64() is not checked. > > > 2) If match_u64() failed, return value is set to -EINVAL despite that > > > there are other possible errnos. > > > > Ditto. Does this matter? > > > > It's not a big deal, but I think at least return value of match_u64() > should be checked, we don't want to continue with invalid input, right? Yeah, sure. > By the way, match_u64() can return -ERANGE, which can provide more > specific error messge to user. I'm really not convinced going over 64bit range would be all that difficult to spot whether the error code is -EINVAL or -ERANGE. There isn't anything wrong with returning -ERANGE but the fact that that particular function returns an error code doesn't necessarily mean that it *must* be forwarded. Imagine that we used sscanf(buf, "%llu", &value) to parse the number instead. We'd only know whether the parsing would have succeeded or not and would probably return -EINVAL on failure and the behavior would be just fine. This does not matter *at all*. So, idk, I'm not necessarily against it but changing -EINVAL to -ERANGE is pure churn. Nothing material is being improved by that change. Thanks.
Hi, 在 2022/12/01 18:08, Tejun Heo 写道: > On Thu, Dec 01, 2022 at 10:15:53AM +0800, Yu Kuai wrote: >> Hi, >> >> 在 2022/12/01 4:32, Tejun Heo 写道: >>> On Wed, Nov 30, 2022 at 09:21:49PM +0800, Li Nan wrote: >>>> From: Yu Kuai <yukuai3@huawei.com> >>>> >>>> 1) There are one place that return value of match_u64() is not checked. >>>> 2) If match_u64() failed, return value is set to -EINVAL despite that >>>> there are other possible errnos. >>> >>> Ditto. Does this matter? >>> >> >> It's not a big deal, but I think at least return value of match_u64() >> should be checked, we don't want to continue with invalid input, right? > > Yeah, sure. > >> By the way, match_u64() can return -ERANGE, which can provide more >> specific error messge to user. > > I'm really not convinced going over 64bit range would be all that difficult > to spot whether the error code is -EINVAL or -ERANGE. There isn't anything > wrong with returning -ERANGE but the fact that that particular function > returns an error code doesn't necessarily mean that it *must* be forwarded. > > Imagine that we used sscanf(buf, "%llu", &value) to parse the number > instead. We'd only know whether the parsing would have succeeded or not and > would probably return -EINVAL on failure and the behavior would be just > fine. This does not matter *at all*. > > So, idk, I'm not necessarily against it but changing -EINVAL to -ERANGE is > pure churn. Nothing material is being improved by that change. Thanks for the review and explanation, I'll just keep the addition of return value checking of the former 2 patches. Thanks, Kuai
diff --git a/block/blk-iocost.c b/block/blk-iocost.c index fd495e823db2..c532129a1456 100644 --- a/block/blk-iocost.c +++ b/block/blk-iocost.c @@ -3202,6 +3202,7 @@ static ssize_t ioc_qos_write(struct kernfs_open_file *of, char *input, substring_t args[MAX_OPT_ARGS]; char buf[32]; int tok; + int err; s64 v; if (!*p) @@ -3209,7 +3210,12 @@ static ssize_t ioc_qos_write(struct kernfs_open_file *of, char *input, switch (match_token(p, qos_ctrl_tokens, args)) { case QOS_ENABLE: - match_u64(&args[0], &v); + err = match_u64(&args[0], &v); + if (err) { + ret = err; + goto out_unlock; + } + enable = v; continue; case QOS_CTRL: @@ -3238,8 +3244,12 @@ static ssize_t ioc_qos_write(struct kernfs_open_file *of, char *input, break; case QOS_RLAT: case QOS_WLAT: - if (match_u64(&args[0], &v)) + err = match_u64(&args[0], &v); + if (err) { + ret = err; goto out_unlock; + } + qos[tok] = v; break; case QOS_MIN: @@ -3374,6 +3384,7 @@ static ssize_t ioc_cost_model_write(struct kernfs_open_file *of, char *input, substring_t args[MAX_OPT_ARGS]; char buf[32]; int tok; + int err; u64 v; if (!*p) @@ -3399,8 +3410,13 @@ static ssize_t ioc_cost_model_write(struct kernfs_open_file *of, char *input, tok = match_token(p, i_lcoef_tokens, args); if (tok == NR_I_LCOEFS) goto out_unlock; - if (match_u64(&args[0], &v)) + + err = match_u64(&args[0], &v); + if (err) { + ret = err; goto out_unlock; + } + u[tok] = v; user = true; }