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);
}
/**
--
2.34.1On 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
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
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/
© 2016 - 2025 Red Hat, Inc.