netdev - Re: [net-next 13/15] net/mlx5: Skip inline mode check after mlx5_eswitch_enable

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: <ZIEQU7cLLXXk1Nqy@ziepe.ca>
Date: Wed, 7 Jun 2023 20:18:43 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Jakub Kicinski <kuba@...nel.org>
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, Jun 07, 2023 at 09:19:09AM -0700, Jakub Kicinski wrote:

> > 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.

The categories exist in our workflow - we have two patch streams to
Linus and the cc stable mechanism for Greg and others. This is what
Greg/Linus defined. Maintainers have to funnel patches into these
streams.

I said people have trouble categorizing their own work into each
stream. Many people legitimately disagree what should go in each
stream. If patch comes to the list with the best guess then the
community/maintainer can help and create some consistency.

If people self-censor their Fixes lines this is harder.

Further, there is a legitimate disagreement on what should and should
not be backported. Keeping the Fixes lines allows everyone to make
their own choices. If something doesn't go to -rc because it doesn't
meet Linus's threshold it may still need to be backported.

> > But mark it with Fixes regardless
> 
> Every subsystem can make their own rules. In netdev Fixes go to net.

I don't really like this position that every maintainer and every
subsystem can do whatever they want.

Jason