linux-kernel - Re: [PATCH v4 1/2] serial: sifive: lock port in startup()/shutdown() callbacks

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: <2025042202-compare-entrap-0089@gregkh>
Date: Tue, 22 Apr 2025 12:50:52 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Ryo Takakura <ryotkkr98@...il.com>, alex@...ti.fr,
	aou@...s.berkeley.edu, bigeasy@...utronix.de,
	conor.dooley@...rochip.com, jirislaby@...nel.org,
	john.ogness@...utronix.de, palmer@...belt.com,
	paul.walmsley@...ive.com, pmladek@...e.com,
	samuel.holland@...ive.com, u.kleine-koenig@...libre.com,
	linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
	linux-serial@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v4 1/2] serial: sifive: lock port in startup()/shutdown()
 callbacks

On Tue, Apr 22, 2025 at 12:20:42PM +0200, Vlastimil Babka wrote:
> On 4/5/25 09:35, Greg KH wrote:
> > On Sat, Apr 05, 2025 at 01:43:38PM +0900, Ryo Takakura wrote:
> >> startup()/shutdown() callbacks access SIFIVE_SERIAL_IE_OFFS.
> >> The register is also accessed from write() callback.
> >> 
> >> If console were printing and startup()/shutdown() callback
> >> gets called, its access to the register could be overwritten.
> >> 
> >> Add port->lock to startup()/shutdown() callbacks to make sure
> >> their access to SIFIVE_SERIAL_IE_OFFS is synchronized against
> >> write() callback.
> >> 
> >> Signed-off-by: Ryo Takakura <ryotkkr98@...il.com>
> >> Cc: stable@...r.kernel.org
> > 
> > What commit id does this fix?
> 
> > Why does patch 1/2 need to go to stable, but patch 2/2 does not?  Please
> > do not mix changes like this in the same series, otherwise we have to
> > split them up manually when we apply them to the different branches,
> > right?
> 
> I admit it's surprising to see such a request as AFAIK it's normally done to
> mix stable fixes and new features in the same series (especially when the
> patches depend on each other), and ordering the fixes first and marking only
> them as stable should be sufficient. We do that all the time in -mm. I
> thought that stable works with stable marked commits primarily, not series?

Yes, but when picking which "branch" to apply a series to, what would
you do if you have some "fix some bugs, then add some new features" in a
single patch series?  The one to go to -final or the one for the next
-rc1?

I see a lot of bugfixes delayed until -rc1 because of this issue, and
it's really not a good idea at all.

> Also since the patches are AFAIU dependent on each other, sending them
> separately makes the mainline development process more difficult, as
> evidenced by the later revisions having to add notes in the diffstat area
> etc. This would go against the goal that stable process does not add extra
> burden to the mainline process, no?

If they are dependent on each other, that's the creator's issue, not the
maintainer's issue, no?  :)

Submit the bug fixes, get them merged, and then submit the new features.

thanks,

greg k-h