netdev - Re: [PATCH net-next v3 00/11] devlink: retain error in struct devlink

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 19 Oct 2023 23:50:03 +0200
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: Jiri Pirko <jiri@...nulli.us>
CC: <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>, Simon Horman <horms@...nel.org>, 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>
Subject: Re: [PATCH net-next v3 00/11] devlink: retain error in struct
 devlink_fmsg

On 10/19/23 15:44, Jiri Pirko wrote:
> Wed, Oct 18, 2023 at 10:26:36PM CEST, przemyslaw.kitszel@...el.com wrote:
>> Extend devlink fmsg to retain error (patch 1),
>> so drivers could omit error checks after devlink_fmsg_*() (patches 2-10),
>> and finally enforce future uses to follow this practice by change to
>> return void (patch 11)
>>
>> Note that it was compile tested only.
>>
>> bloat-o-meter for whole series:
>> add/remove: 8/18 grow/shrink: 23/40 up/down: 2017/-5833 (-3816)
>>
>> changelog:
>> v3: set err to correct value, thanks to Simon and smatch
>>     (mlx5 patch, final patch);
> 
> 2 nits:
> - always better to have per-patch changelog so it is clear for the
>    reviewers what exactly did you change and where.

agree that adding changelog also to patches would be better

> - if you do any change in a patch, you should drop the
>    acked/reviewed/signedoff tags and get them again from people.

Here opinions differ widely, and my understanding was "it depends".
Noted to always drop yours.

On one side you have just rebased patches (different context of review),
then with trivial conflict fixed, then with minor change (as here,
0-init to retval, those are things that I believe most reviewers don't
want to look again at.
Then patches with some improvement that somebody suggested (as reviewer,
I want to see what could have been done better and I didn't notice).

In the above cases there is both time to react and no much harm keeping
RB. Things I think that most reviewers and maintainers would like to
drop RB start at "significant changes such as 'business' logic change",
which is of course a fuzzy line.

Always dropping is an easy solution, perhaps too easy ;)

> 
> that being said:
> set-
> Reviewed-by: Jiri Pirko <jiri@...dia.com>
> 

Thank you!