linux-kernel - Re: [PATCH net-next v2] tg3: Remove residual error handling in tg3

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Fri, 29 Mar 2024 14:51:18 +0300
From: Nikita Kiryushin <kiryushin@...ud.ru>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Michael Chan <mchan@...adcom.com>,
 Pavan Chebbi <pavan.chebbi@...adcom.com>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, "Rafael J. Wysocki" <rjw@...ysocki.net>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 lvc-project@...uxtesting.org, Michael Chan <michael.chan@...adcom.com>
Subject: Re: [PATCH net-next v2] tg3: Remove residual error handling in
 tg3_suspend

Thank you for the feedback!

> Please stop adding these lines, they are unless.
> If you want to attribute the work to some project / employer
> add (SVACE) to your author lines.
>
Tool used signature line (the SVACE one) in that format was put in the
patch as required by lvc-project protocols. I guess, it is used for some
automation by the project, but I can agree, that the needs of some
specific project should not add cruft to the general code base/version control.

Thank you for expressing annoyance about it, I hope it will trigger conversation
about better way of adding the needed information for further iterations of the
project (as this thread is being mirrored to the project mailing list).
> How is deleting dead code a fix?
Originally, that was intended as a fix of a potential problematic case, that
tg3_power_down_prepare() could change in the future, returning a
non-zero status (which would make the removed code not dead, but undead).
But than, as patch evolved, it became a straight up dead code removal.
Probably, I should have removed the "fixes" line at that point, but
I think it still useful as a reference point to know, after which commit this patch
becomes relevant (to know, if it should be back-ported to some version or not,
for example).As I guess from the guide, patches "Fixes:" tag has some special treatment in the development cycle, but what would be more appropriate in that case?
> Hopefully you can find in there whether we suggest posting new versions
> in reply to the old ones..
Thank you for pointing this out! Missed the part about "The new version of
patches should be posted as a separate thread, not as a reply to the
previous posting. Change log should include a link to the previous posting"
while reading netdev guide.

Should I resubmit the patch in the separate thread now? If so, should I
make any changes to it (as discussed)? Would it bump the patch version
(the patch would essentially be the same, as only some metadata like
change log itself would change)?