linux-kernel - Re: [PATCH v3 00/16] Converge on using secs_to

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: <594169fd-5ba6-42d5-ad35-bb8c7720904b@sirena.org.uk>
Date: Wed, 26 Feb 2025 22:26:46 +0000
From: Mark Brown <broonie@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Easwar Hariharan <eahariha@...ux.microsoft.com>,
	Yaron Avizrat <yaron.avizrat@...el.com>,
	Oded Gabbay <ogabbay@...nel.org>,
	Julia Lawall <Julia.Lawall@...ia.fr>,
	Nicolas Palix <nicolas.palix@...g.fr>,
	James Smart <james.smart@...adcom.com>,
	Dick Kennedy <dick.kennedy@...adcom.com>,
	"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
	Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
	David Sterba <dsterba@...e.com>, Ilya Dryomov <idryomov@...il.com>,
	Dongsheng Yang <dongsheng.yang@...ystack.cn>,
	Jens Axboe <axboe@...nel.dk>, Xiubo Li <xiubli@...hat.com>,
	Damien Le Moal <dlemoal@...nel.org>,
	Niklas Cassel <cassel@...nel.org>, Carlos Maiolino <cem@...nel.org>,
	"Darrick J. Wong" <djwong@...nel.org>,
	Sebastian Reichel <sre@...nel.org>, Keith Busch <kbusch@...nel.org>,
	Christoph Hellwig <hch@....de>, Sagi Grimberg <sagi@...mberg.me>,
	Frank Li <Frank.Li@....com>, Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	Shyam Sundar S K <Shyam-sundar.S-k@....com>,
	Hans de Goede <hdegoede@...hat.com>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Selvin Xavier <selvin.xavier@...adcom.com>,
	Kalesh AP <kalesh-anakkur.purayil@...adcom.com>,
	Jason Gunthorpe <jgg@...pe.ca>, Leon Romanovsky <leon@...nel.org>,
	cocci@...ia.fr, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	linux-sound@...r.kernel.org, linux-btrfs@...r.kernel.org,
	ceph-devel@...r.kernel.org, linux-block@...r.kernel.org,
	linux-ide@...r.kernel.org, linux-xfs@...r.kernel.org,
	linux-pm@...r.kernel.org, linux-nvme@...ts.infradead.org,
	linux-spi@...r.kernel.org, imx@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org,
	platform-driver-x86@...r.kernel.org,
	ibm-acpi-devel@...ts.sourceforge.net, linux-rdma@...r.kernel.org,
	Takashi Iwai <tiwai@...e.de>,
	Carlos Maiolino <cmaiolino@...hat.com>
Subject: Re: [PATCH v3 00/16] Converge on using secs_to_jiffies() part two

On Wed, Feb 26, 2025 at 12:38:51PM -0800, Andrew Morton wrote:
> On Wed, 26 Feb 2025 11:29:53 +0000 Mark Brown <broonie@...nel.org> wrote:

> > Please don't combine patches for multiple subsystems into a single
> > series if there's no dependencies between them, it just creates
> > confusion about how things get merged, problems for tooling and makes
> > everything more noisy.  It's best to split things up per subsystem in
> > that case.

> I asked for this.  I'll merge everything, spend a few weeks gathering
> up maintainer acks.  Anything which a subsystem maintainer merges will
> be reported by Stephen and I'll drop that particular patch.

> This way, nothing gets lost.  I take this approach often and it works.

I've only started seeing these in the past few weeks, but we do have a
bunch of people routinely doing cross tree stuff who split things up and
it seems to work OK there.

> If these were sent as a bunch of individual patches then it would be up
> to the sender to keep track of what has been merged and what hasn't. 
> That person will be resending some stragglers many times.  Until they
> give up and some patches get permanently lost.

Surely the sender can just CC you on each individual thing just as well?
Ensuring things get picked up is great, but it's not clear to me that
copying everyone on a cross tree series is helping with that.

> Scale all that across many senders and the whole process becomes costly
> and unreliable.  Whereas centralizing it on akpm is more efficient,
> more reliable, more scalable, lower latency and less frustrating for
> senders.

Whereas copying everyone means all the maintainers see something that
looks terribly complicated in their inboxes and have to figure out if
there are actually any dependencies in the series and how it's supposed
to be handed, and then every reply goes to a huge CC list.  That's not
good for either getting people to look at things or general noise
avoidance, especially for people who are expecting to get cross tree
serieses which do have dependencies that need to be managed.

There's also some bad failure modes as soon as anyone has any sort of
comment on the series, suddenly everyone's got a coding style debate or
whatever in their inboxes they can pile into.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)