netdev - Re: [patch net-next 01/10] genetlink: don't merge dumpit split op for different cmds into single iter

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: Thu, 12 Oct 2023 13:58:50 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...nulli.us>
CC: <netdev@...r.kernel.org>, <pabeni@...hat.com>, <davem@...emloft.net>,
	<edumazet@...gle.com>, <johannes@...solutions.net>
Subject: Re: [patch net-next 01/10] genetlink: don't merge dumpit split op for
 different cmds into single iter



On 10/11/2023 9:47 AM, Jakub Kicinski wrote:
> On Wed, 11 Oct 2023 13:27:05 +0200 Jiri Pirko wrote:
>>> Yeah, we need fixes semantics written down somewhere.
>>> I can do it, sure.  
>>
>> I found 2 mentions that relate to netdev regarging Fixes:
>>
>> Quoting Documentation/process/submitting-patches.rst:
>> If your patch fixes a bug in a specific commit, e.g. you found an issue using
>> ``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
>> the SHA-1 ID, and the one line summary. 
>>
>> Quoting Documentation/process/maintainer-netdev.rst:
>>  - for fixes the ``Fixes:`` tag is required, regardless of the tree
>>
>> This patch fixes a bug, sure, bug is not hit by existing code, but still
>> it is present.
>>
>> Why it is wrong to put "Fixes" in this case?
>> Could you please document this?
> 
> I think you're asking me to document what a bug is because the existing
> doc clearly says Fixes is for bugs. If the code does not misbehave,
> there is no bug.
> 

Well this code misbehaves if given the right input. We just don't give
it that input today. I would have called that a bug too. But from a
strict sense of "can you make this fail on a current kernel" the answer
is no, since no families exist which have this requirement until after
this series.