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:   Tue, 28 Nov 2023 00:23:54 +0530
From:   Abhinav Singh <singhabhinav9051571833@...il.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     tony.luck@...el.com, qiuxu.zhuo@...el.com, james.morse@....com,
        mchehab@...nel.org, rric@...nel.org, linux-edac@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        linux-kernel-mentees@...ts.linuxfoundation.org
Subject: Re: [PATCH] driver : edac : Fix warning using plain integer as NULL

On 11/28/23 00:09, Borislav Petkov wrote:
> On Mon, Nov 27, 2023 at 11:53:02PM +0530, Abhinav Singh wrote:
>> Hello, thanks for reviewing this. As of now this is only a warning issue in
>> kernel. I saw this post by linus
>> https://www.spinics.net/lists/linux-sparse/msg10066.html and thought of
>> submitting a patch. Also a similar patch of mine got accepted
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2560740.html,
>> so thought about opening this one as well.
> 
> Lemme try to understand what you're saying: just because someone
> accepted a patch of yours, then others should not ask you to improve
> your commit message so that it explains *why* a change should be done.
> 
> How about you put the gist of what Linus is saying in your commit
> message? Don't you think it would be a much better commit message then?
> 
> Especially if it explains why, even if it is the case that 0 == NULL, we
> don't want those in the kernel.
> 
> Hmmm?
> 
Hello, my sincere apologies, I wrongly interpreted that you were asking 
for a reason in reply rather than in the commit message itself. Yeah I 
agree putting a reason in the commit message will make more sense. Just 
to be correct this time, I need to put a reason why this needs to be 
fixed, in the patch itself, right?

Thank You,
Abhinav Singh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ