| Message ID | 75495d45-cfc4-9740-39e4-bd4c3e71232b@users.sourceforge.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Jan 22, 2017 at 09:31:29AM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 21 Jan 2017 21:23:06 +0100 > > A local variable was set to an error code before a concrete error situation > was detected. Thus move the corresponding assignments into if branches > to indicate a software failure there. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > block/blk-throttle.c | 23 +++++++++++++---------- > 1 file changed, 13 insertions(+), 10 deletions(-) > > diff --git a/block/blk-throttle.c b/block/blk-throttle.c > index 6f4c96e5f86b..51d112deb02e 100644 > --- a/block/blk-throttle.c > +++ b/block/blk-throttle.c > @@ -1327,27 +1327,30 @@ static ssize_t tg_set_max(struct kernfs_open_file *of, > break; > ctx.body += len; > > - ret = -EINVAL; > p = tok; > strsep(&p, "="); > - if (!p || (sscanf(p, "%llu", &val) != 1 && strcmp(p, "max"))) > + if (!p || (sscanf(p, "%llu", &val) != 1 && strcmp(p, "max"))) { > + ret = -EINVAL; > goto out_finish; > + } Sorry, I don't like this patch. We know the next error if we encounter one will be EINVAL until we change it. Your patch doesn't introduce a functual change and doesn't improve readability, so I don't really see a point for it. Byte, Johannes
>> @@ -1327,27 +1327,30 @@ static ssize_t tg_set_max(struct kernfs_open_file *of, >> break; >> ctx.body += len; >> >> - ret = -EINVAL; >> p = tok; >> strsep(&p, "="); >> - if (!p || (sscanf(p, "%llu", &val) != 1 && strcmp(p, "max"))) >> + if (!p || (sscanf(p, "%llu", &val) != 1 && strcmp(p, "max"))) { >> + ret = -EINVAL; >> goto out_finish; >> + } > > Sorry, I don't like this patch. We know the next error if we encounter one > will be EINVAL until we change it. Thanks for your constructive feedback. > Your patch doesn't introduce a functual change and doesn't improve readability, > so I don't really see a point for it. We have got different preferences for the placement of error code settings. Do you care about run time changes there? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 23, 2017 at 11:00:15AM +0100, SF Markus Elfring wrote: > >> @@ -1327,27 +1327,30 @@ static ssize_t tg_set_max(struct kernfs_open_file *of, > >> break; > >> ctx.body += len; > >> > >> - ret = -EINVAL; > >> p = tok; > >> strsep(&p, "="); > >> - if (!p || (sscanf(p, "%llu", &val) != 1 && strcmp(p, "max"))) > >> + if (!p || (sscanf(p, "%llu", &val) != 1 && strcmp(p, "max"))) { > >> + ret = -EINVAL; > >> goto out_finish; > >> + } > > > > Sorry, I don't like this patch. We know the next error if we encounter one > > will be EINVAL until we change it. > > Thanks for your constructive feedback. > > > > Your patch doesn't introduce a functual change and doesn't improve readability, > > so I don't really see a point for it. > > We have got different preferences for the placement of error code settings. Yes we do, so what's the point? Both are OK. Please don't go down that road it opens so much potential for needless bikeshedding and waste all of our (including your) time. Thanks, Johannes
>> We have got different preferences for the placement of error code settings. > Yes we do, so what's the point? Both are OK. Can a function implementation be executed a bit faster in the case that error codes will usually only matter if they would be set after a concrete software failure > Please don't go down that road it opens so much potential for needless bikeshedding > and waste all of our (including your) time. I would appreciate to clarify involved run time consequences a bit more. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/23/2017 05:06 AM, SF Markus Elfring wrote: >>> We have got different preferences for the placement of error code settings. >> Yes we do, so what's the point? Both are OK. > > Can a function implementation be executed a bit faster in the case > that error codes will usually only matter if they would be set after > a concrete software failure Don't turn this into a troll fest. Maintainability trumps performance. Every time. See previous email for reasoning for that. >> Please don't go down that road it opens so much potential for needless bikeshedding >> and waste all of our (including your) time. > > I would appreciate to clarify involved run time consequences a bit more. How about you go and benchmark the before and after, and present some compelling evidence based on those tests for why the change should be made? The onus is on the submitter here, not the reviewer. As I said in the previous email, don't bother sending these types of patches for the block layer again. They are just going to be ignored.
diff --git a/block/blk-throttle.c b/block/blk-throttle.c index 6f4c96e5f86b..51d112deb02e 100644 --- a/block/blk-throttle.c +++ b/block/blk-throttle.c @@ -1327,27 +1327,30 @@ static ssize_t tg_set_max(struct kernfs_open_file *of, break; ctx.body += len; - ret = -EINVAL; p = tok; strsep(&p, "="); - if (!p || (sscanf(p, "%llu", &val) != 1 && strcmp(p, "max"))) + if (!p || (sscanf(p, "%llu", &val) != 1 && strcmp(p, "max"))) { + ret = -EINVAL; goto out_finish; + } - ret = -ERANGE; - if (!val) + if (!val) { + ret = -ERANGE; goto out_finish; + } - ret = -EINVAL; - if (!strcmp(tok, "rbps")) + if (!strcmp(tok, "rbps")) { v[0] = val; - else if (!strcmp(tok, "wbps")) + } else if (!strcmp(tok, "wbps")) { v[1] = val; - else if (!strcmp(tok, "riops")) + } else if (!strcmp(tok, "riops")) { v[2] = min_t(u64, val, UINT_MAX); - else if (!strcmp(tok, "wiops")) + } else if (!strcmp(tok, "wiops")) { v[3] = min_t(u64, val, UINT_MAX); - else + } else { + ret = -EINVAL; goto out_finish; + } } tg->bps[READ] = v[0];