linux-kernel - Re: [PATCH -mmotm] efi: drop kmemleak

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] [day] [month] [year] [list]

Message-ID: <70d2a620-d9d8-f351-78fb-1135d264d824@lca.pw>
Date:   Sat, 29 Dec 2018 15:22:09 -0500
From:   Qian Cai <cai@....pw>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Linux-MM <linux-mm@...ck.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -mmotm] efi: drop kmemleak_ignore() for page allocator

On 12/29/18 4:17 AM, Ard Biesheuvel wrote:
> On Fri, 28 Dec 2018 at 04:04, Andrew Morton <akpm@...ux-foundation.org> wrote:
>>
>> On Wed, 26 Dec 2018 16:31:59 +0100 Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:
>>
>>> Please stop sending EFI patches if you can't be bothered to
>>> test/reproduce against the EFI tree.
>>
>> um, sorry, but that's a bit strong.  Finding (let alone fixing) a bug
>> in EFI is a great contribution (thanks!) and the EFI maintainers are
>> perfectly capable of reviewing and testing the proposed fix.  Or of
>> fixing the bug by other means.
>>
> 
> Qian did spot some issues recently, which was really helpful. But I
> really think that reporting all issues you find against the -mmotm
> tree because that happens to be your preferred tree for development is
> not the correct approach.
> 
>> Let's not beat people up for helping us in a less-than-perfect way, no?
> 
> Fair enough. But asking people to ensure that an issue they found
> actually exists on the subsystem tree in question is not that much to
> ask, is it?

It is not too much to ask to test on EFI subsystem tree only for this patch, but
if every maintainer asked for the same thing to test each subsystem tree after
found a bug even a trivial one in -mmotm or linux-next, it then become an issue.

There are people genuinely interested in the kernel in general rather than focus
on a few subsystems (yet). There are many subsystem git trees out there. It at
least needs to figure out which branch to test and adjust the config file
accordingly. Those subsystem trees usually are not well-documented like
linux-next or -mmotm trees. Then, they may need to deal with the subsystem
tree-specific issues.

Those people may just better switch to use mainline instead where they don't
need to bother testing the subsystem tree for every single patch. However, that
will cause delay in fixing those issues because mainline is usually a bit lag
behind the development.