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: Fri, 5 Apr 2024 08:05:50 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Finn Thain <fthain@...ux-m68k.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby <jirislaby@...nel.org>, 
	Benjamin Herrenschmidt <benh@...nel.crashing.org>, Michael Ellerman <mpe@...erman.id.au>, 
	Nicholas Piggin <npiggin@...il.com>, Christophe Leroy <christophe.leroy@...roup.eu>, 
	"Aneesh Kumar K.V" <aneesh.kumar@...nel.org>, "Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>, 
	linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org, 
	linux-serial@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH] serial/pmac_zilog: Remove flawed mitigation for rx irq flood

On Fri, Apr 5, 2024 at 1:15 AM Finn Thain <fthain@...ux-m68k.org> wrote:
> On Thu, 4 Apr 2024, Andy Shevchenko wrote:
>
> > > > > ---
> > > > (here is a good location for Cc:)
> > >
> > > Documentation/process/submitting-patches.rst indicats that it should
> > > be above the "---" separator together with Acked-by etc. Has this
> > > convention changed recently?
> >
> > I see, I will prepare a patch to discuss this aspect.
>
> If you are going to veto patches on the basis of rules yet unwritten, I
> think you risk turning the kernel development process into a lottery.

It's already a lottery, if you haven't noticed, i.e. it highly relies
on the style preferences of the maintainers and is yet undocumented (a
few years ago it was a new section introduced for closing this gap).

> How many other patches presently under review will need to be dropped just
> in case they don't conform with possible future rules?

What you are saying is pure speculation.

I rely on at least two things (besides already explained):
- the fact that Submitting Patches refers to the commit message
reduction due to the unnecessariness of some lines
- my experience and common sense (why duplicate the data?).

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ