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:   Mon, 8 Aug 2022 12:37:46 -0300
From:   "Guilherme G. Piccoli" <>
To:     Greg Kroah-Hartman <>
Cc:     Evan Green <>,,
        LKML <>,
        Ard Biesheuvel <>,
        Andrew Morton <>,,
        Petr Mladek <>,,,,,,,,,,
        Andy Shevchenko <>,
        Arnd Bergmann <>, Borislav Petkov <>,
        Jonathan Corbet <>,,,,,,,,, Kees Cook <>,,,,,,,, Alan Stern <>,
        Thomas Gleixner <>,,, Will Deacon <>,
        David Gow <>,
        Julius Werner <>
Subject: Re: [PATCH v2 03/13] firmware: google: Test spinlock on panic path to
 avoid lockups

On 08/08/2022 12:26, Greg Kroah-Hartman wrote:
> [...]
>> Ard / Greg, do you think you could get this patch through your -next (or
>> -fixes) trees? Not sure which tree is the most common for picking GSMI
>> stuff.
> Picking out an individual patch from a series with as many responses and
> threads like this one is quite difficult.
> Just resend this as a stand-alone patch if you want it applied
> stand-alone as our tools want to apply a whole patch series at once.
>> I'm trying to get these fixes merged individually in their trees to not
>> stall the whole series and increase the burden of re-submitting.
> The burden is on the submitter, not the maintainer as we have more
> submitters than reviewers/maintainers.

I understand, thanks for letting me know!

Let me clarify / ask something: this series, for example, is composed as
a bunch of patches "centered" around the same idea, panic notifiers
improvements/fixes. But its patches belong to completely different
subsystems, like EFI/misc, architectures (alpha, parisc, arm), core
kernel code, etc.

What is the best way of getting this merged?
(a) Re-send individual patches with the respective Review/ACK tags to
the proper subsystem, or;

(b) Wait until the whole series is ACKed/Reviewed, and a single
maintainer (like you or Andrew, for example) would pick the whole series
and apply at once, even if it spans across multiple parts of the kernel?

Let me know what is the general preference of the kernel maintainers,
and I'll gladly follow that =)



Powered by blists - more mailing lists