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]
Message-ID: <20230607091909.321fc5d7@kernel.org>
Date: Wed, 7 Jun 2023 09:19:09 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Saeed Mahameed <saeed@...nel.org>, "David S. Miller"
 <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, Eric Dumazet
 <edumazet@...gle.com>, Saeed Mahameed <saeedm@...dia.com>,
 netdev@...r.kernel.org, Tariq Toukan <tariqt@...dia.com>, Leon Romanovsky
 <leonro@...dia.com>, linux-rdma@...r.kernel.org, Jiri Pirko
 <jiri@...dia.com>
Subject: Re: [net-next 13/15] net/mlx5: Skip inline mode check after
 mlx5_eswitch_enable_locked() failure

On Wed, 7 Jun 2023 11:10:42 -0300 Jason Gunthorpe wrote:
> On Tue, Jun 06, 2023 at 10:01:17PM -0700, Jakub Kicinski wrote:
> > On Tue,  6 Jun 2023 00:12:17 -0700 Saeed Mahameed wrote:  
> > > Fixes: bffaa916588e ("net/mlx5: E-Switch, Add control for inline mode")
> > > Fixes: 8c98ee77d911 ("net/mlx5e: E-Switch, Add extack messages to devlink callbacks")  
> > 
> > The combination of net-next and Fixes is always odd.
> > Why? 
> > Either it's important enough to be a fix or its not important 
> > and can go to net-next...  
> 
> Generally I tell people to mark things as Fixes if it is a fix,
> regardless of how small, minor or unimportant.

Yes, exactly, we do the same, but also to send them all to net.

> It helps backporters because they can suck in the original patch and
> all the touchups then test that result. If people try to predict if it
> is "important" or not they get it wrong quite often.
> 
> Fixes is not supposed to mean "this is important" or "send this to
> -rc" or "apply it to -stable"

Agreed with the distinction that we consider every fix -rc worthy.
We'll obviously apply our own judgment but submitter should send all
fixes against net.

> If it is really important add a 'cc: stable'.
> 
> If it is sort of important then send it to the -rc tree.
> 
> Otherwise dump it in the merge window.

You just said that people can't predict the importance of their fixes
and yet you draw categories.

> But mark it with Fixes regardless

Every subsystem can make their own rules. In netdev Fixes go to net.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ