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
| ||
|
Message-ID: <YvOqimNnybaCDDBm@kroah.com> Date: Wed, 10 Aug 2022 14:54:34 +0200 From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> To: "Guilherme G. Piccoli" <gpiccoli@...lia.com> Cc: Evan Green <evgreen@...omium.org>, linux-efi@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>, Ard Biesheuvel <ardb@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, bhe@...hat.com, Petr Mladek <pmladek@...e.com>, kexec@...ts.infradead.org, linux-hyperv@...r.kernel.org, netdev@...r.kernel.org, x86@...nel.org, kernel-dev@...lia.com, kernel@...ccoli.net, halves@...onical.com, fabiomirmar@...il.com, alejandro.j.jimenez@...cle.com, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Arnd Bergmann <arnd@...db.de>, Borislav Petkov <bp@...en8.de>, Jonathan Corbet <corbet@....net>, d.hatayama@...fujitsu.com, dave.hansen@...ux.intel.com, dyoung@...hat.com, feng.tang@...el.com, mikelley@...rosoft.com, hidehiro.kawai.ez@...achi.com, jgross@...e.com, john.ogness@...utronix.de, Kees Cook <keescook@...omium.org>, luto@...nel.org, mhiramat@...nel.org, mingo@...hat.com, paulmck@...nel.org, peterz@...radead.org, rostedt@...dmis.org, senozhatsky@...omium.org, Alan Stern <stern@...land.harvard.edu>, Thomas Gleixner <tglx@...utronix.de>, vgoyal@...hat.com, vkuznets@...hat.com, Will Deacon <will@...nel.org>, David Gow <davidgow@...gle.com>, Julius Werner <jwerner@...omium.org> Subject: Re: [PATCH v2 03/13] firmware: google: Test spinlock on panic path to avoid lockups On Mon, Aug 08, 2022 at 12:37:46PM -0300, Guilherme G. Piccoli wrote: > 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; Yes. > (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? No, only do this after a kernel release cycle happens and there are straggler patches that did not get picked up by the relevant subsystem maintainers. thanks, greg k-h
Powered by blists - more mailing lists