lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20231019130037.GI2100445@kernel.org> Date: Thu, 19 Oct 2023 15:00:37 +0200 From: Simon Horman <horms@...nel.org> To: Przemek Kitszel <przemyslaw.kitszel@...el.com> Cc: Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Shannon Nelson <shannon.nelson@....com>, Michael Chan <michael.chan@...adcom.com>, Cai Huoqing <cai.huoqing@...ux.dev>, George Cherian <george.cherian@...vell.com>, Danielle Ratson <danieller@...dia.com>, Moshe Shemesh <moshe@...dia.com>, Saeed Mahameed <saeedm@...dia.com>, Ariel Elior <aelior@...vell.com>, Manish Chopra <manishc@...vell.com>, Igor Russkikh <irusskikh@...vell.com>, Coiby Xu <coiby.xu@...il.com>, Brett Creeley <brett.creeley@....com>, Sunil Goutham <sgoutham@...vell.com>, Linu Cherian <lcherian@...vell.com>, Geetha sowjanya <gakula@...vell.com>, Jerin Jacob <jerinj@...vell.com>, hariprasad <hkelam@...vell.com>, Subbaraya Sundeep <sbhatta@...vell.com>, Ido Schimmel <idosch@...dia.com>, Petr Machata <petrm@...dia.com>, Eran Ben Elisha <eranbe@...dia.com>, Aya Levin <ayal@...lanox.com>, Leon Romanovsky <leon@...nel.org>, linux-kernel@...r.kernel.org, Benjamin Poirier <bpoirier@...e.com>, Jesse Brandeburg <jesse.brandeburg@...el.com>, Jiri Pirko <jiri@...dia.com> Subject: Re: [PATCH net-next v3 01/11] devlink: retain error in struct devlink_fmsg On Wed, Oct 18, 2023 at 10:26:37PM +0200, Przemek Kitszel wrote: > Retain error value in struct devlink_fmsg, to relieve drivers from > checking it after each call. > Note that fmsg is an in-memory builder/buffer of formatted message, > so it's not the case that half baked message was sent somewhere. > > We could find following scheme in multiple drivers: > err = devlink_fmsg_obj_nest_start(fmsg); > if (err) > return err; > err = devlink_fmsg_string_pair_put(fmsg, "src", src); > if (err) > return err; > err = devlink_fmsg_something(fmsg, foo, bar); > if (err) > return err; > // and so on... > err = devlink_fmsg_obj_nest_end(fmsg); > > With retaining error API that translates to: > devlink_fmsg_obj_nest_start(fmsg); > devlink_fmsg_string_pair_put(fmsg, "src", src); > devlink_fmsg_something(fmsg, foo, bar); > // and so on... > devlink_fmsg_obj_nest_end(fmsg); > > What means we check error just when is time to send. > > Possible error scenarios are developer error (API misuse) and memory > exhaustion, both cases are good candidates to choose readability > over fastest possible exit. > > Note that this patch keeps returning errors, to allow per-driver conversion > to the new API, but those are not needed at this point already. > > This commit itself is an illustration of benefits for the dev-user, > more of it will be in separate commits of the series. > > Reviewed-by: Jesse Brandeburg <jesse.brandeburg@...el.com> > Reviewed-by: Jiri Pirko <jiri@...dia.com> > Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@...el.com> ... > @@ -1027,14 +934,12 @@ int devlink_fmsg_binary_pair_put(struct devlink_fmsg *fmsg, const char *name, Hi Przemek, The line before this hunk is: err = devlink_fmsg_binary_put(fmsg, value + offset, data_size); And, as of this patch, the implementation of devlink_fmsg_binary_pair_nest_start() looks like this: int devlink_fmsg_binary_put(struct devlink_fmsg *fmsg, const void *value, u16 value_len) { if (!fmsg->putting_binary) return -EINVAL; return devlink_fmsg_put_value(fmsg, value, value_len, NLA_BINARY); } Which may return an error, if the if condition is met, without setting fmsg->err. > if (err) > break; > /* Exit from loop with a break (instead of > - * return) to make sure putting_binary is turned off in > - * devlink_fmsg_binary_pair_nest_end > + * return) to make sure putting_binary is turned off > */ > } > > - end_err = devlink_fmsg_binary_pair_nest_end(fmsg); > - if (end_err) > - err = end_err; Prior to this patch, the value of err from the loop above was preserved, unless devlink_fmsg_binary_pair_nest_end generated an error. > + err = devlink_fmsg_binary_pair_nest_end(fmsg); But now it looks like this is only the case if fmsg->err corresponds to err when the loop was exited. Or in other words, the err returned by devlink_fmsg_binary_put() is not propagated to the caller if !fmsg->putting_binary. If so, is this intentional? > + fmsg->putting_binary = false; > > return err; > } > -- > 2.38.1 >
Powered by blists - more mailing lists