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@gmail.com Cc: stable@vger.kernel.org --- drivers/tty/serial/sifive.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/drivers/tty/serial/sifive.c b/drivers/tty/serial/sifive.c index 5904a2d4c..054a8e630 100644 --- a/drivers/tty/serial/sifive.c +++ b/drivers/tty/serial/sifive.c @@ -563,8 +563,11 @@ static void sifive_serial_break_ctl(struct uart_port *port, int break_state) static int sifive_serial_startup(struct uart_port *port) { struct sifive_serial_port *ssp = port_to_sifive_serial_port(port); + unsigned long flags;
+ uart_port_lock_irqsave(&ssp->port, &flags); __ssp_enable_rxwm(ssp); + uart_port_unlock_irqrestore(&ssp->port, flags);
return 0; } @@ -572,9 +575,12 @@ static int sifive_serial_startup(struct uart_port *port) static void sifive_serial_shutdown(struct uart_port *port) { struct sifive_serial_port *ssp = port_to_sifive_serial_port(port); + unsigned long flags;
+ uart_port_lock_irqsave(&ssp->port, &flags); __ssp_disable_rxwm(ssp); __ssp_disable_txwm(ssp); + uart_port_unlock_irqrestore(&ssp->port, flags); }
/**
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@gmail.com Cc: stable@vger.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?
thanks,
greg k-h
Hi Greg, thanks for the comments!
On Sat, 5 Apr 2025 08:35:44 +0100, 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@gmail.com Cc: stable@vger.kernel.org
What commit id does this fix?
I believe the issue existed ever since the driver was added by commit 45c054d0815b ("tty: serial: add driver for the SiFive UART").
Why does patch 1/2 need to go to stable, but patch 2/2 does not? Please
The patch 2/2 has nothing to do with existing issue and its only the patch 1/2 that needs to go to stable as discussed [0].
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 see, I'll keep this in mind. Let me resend the two separately with 'Fixes:' tag for the patch 1/2.
Sincerely, Ryo Takakura
thanks,
greg k-h
[0] https://lore.kernel.org/lkml/84sen2fo4b.fsf@jogness.linutronix.de/
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@gmail.com Cc: stable@vger.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?
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?
Thanks, Vlastimil
thanks,
greg k-h
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@gmail.com Cc: stable@vger.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
On 4/22/25 12:50, Greg KH wrote:
On Tue, Apr 22, 2025 at 12:20:42PM +0200, Vlastimil Babka wrote:
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?
As a maintainer I could split it myself.
I see a lot of bugfixes delayed until -rc1 because of this issue, and it's really not a good idea at all.
In my experience, most of the time these fixes are created because a dev:
- works on the code to implement the feature part - while working at the code, spots an existing bug - the bug can be old (Fixes: commit a number of releases ago) - wants to be helpful so isolates the fix separately as an early patch of the series and marks stable because the bug can be serious enough in theory - at the same time there are no known reports of the bug being hit in the wild
In that case I don't see the urgency to fix it ASAP (unless it's e.g. something obviously dangerously exploitable) so it might not be such a bad idea just to put everything towards next rc1.
This very thread seems to be a good example of the above. I see the later version added a Fixes: 45c054d0815b ("tty: serial: add driver for the SiFive UART") which is a v5.2 commit.
Thanks, Vlastimil
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
On Tue, Apr 22, 2025 at 03:07:54PM +0200, Vlastimil Babka wrote:
On 4/22/25 12:50, Greg KH wrote:
On Tue, Apr 22, 2025 at 12:20:42PM +0200, Vlastimil Babka wrote:
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?
As a maintainer I could split it myself.
You must not have that many patches to review, remember, some of us get a few more than others ;)
I see a lot of bugfixes delayed until -rc1 because of this issue, and it's really not a good idea at all.
In my experience, most of the time these fixes are created because a dev:
- works on the code to implement the feature part
- while working at the code, spots an existing bug
- the bug can be old (Fixes: commit a number of releases ago)
- wants to be helpful so isolates the fix separately as an early patch of
the series and marks stable because the bug can be serious enough in theory
- at the same time there are no known reports of the bug being hit in the wild
In that case I don't see the urgency to fix it ASAP (unless it's e.g. something obviously dangerously exploitable) so it might not be such a bad idea just to put everything towards next rc1.
Yes, but then look at the huge number of "bugfixes" that land in -rc1. Is that ok or not? I don't know...
This very thread seems to be a good example of the above. I see the later version added a Fixes: 45c054d0815b ("tty: serial: add driver for the SiFive UART") which is a v5.2 commit.
Agreed, but delaying a known-fix for weeks/months feels bad to me.
thanks,
greg k-h
On Tue 2025-04-22 15:16:21, Greg KH wrote:
On Tue, Apr 22, 2025 at 03:07:54PM +0200, Vlastimil Babka wrote:
On 4/22/25 12:50, Greg KH wrote:
On Tue, Apr 22, 2025 at 12:20:42PM +0200, Vlastimil Babka wrote:
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?
As a maintainer I could split it myself.
You must not have that many patches to review, remember, some of us get a few more than others ;)
I see a lot of bugfixes delayed until -rc1 because of this issue, and it's really not a good idea at all.
In my experience, most of the time these fixes are created because a dev:
- works on the code to implement the feature part
- while working at the code, spots an existing bug
- the bug can be old (Fixes: commit a number of releases ago)
- wants to be helpful so isolates the fix separately as an early patch of
the series and marks stable because the bug can be serious enough in theory
- at the same time there are no known reports of the bug being hit in the wild
In that case I don't see the urgency to fix it ASAP (unless it's e.g. something obviously dangerously exploitable) so it might not be such a bad idea just to put everything towards next rc1.
Yes, but then look at the huge number of "bugfixes" that land in -rc1. Is that ok or not? I don't know...
This very thread seems to be a good example of the above. I see the later version added a Fixes: 45c054d0815b ("tty: serial: add driver for the SiFive UART") which is a v5.2 commit.
Agreed, but delaying a known-fix for weeks/months feels bad to me.
I personally push rc1 regression fixes ASAP. But it has a cost. I do extra careful review, testing, and still I am nervous of causing a regression which might leak to a stable release.
IMHO, it is perfectly fine to delay fixes for bugs which were there for months or years. For example, this patch fixes a bug which has been in the driver since the beginning (2019).
I think that the root of the problem is in the view of the stable release process. I am pretty conservative. My experience is that some problems are caught only in the -rc phase when the kernel gets more testing. I am not sure if stable -rc kernels get the same amount of testing.
Best Regards, Petr
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Petr Mladek -
Ryo Takakura -
Vlastimil Babka