| Message ID | 20230914183831.587273-1-john.ogness@linutronix.de |
|---|---|
| Headers | show |
| Series | serial: wrappers for uart port lock | expand |
On Thu, 14 Sep 2023, John Ogness wrote: > From: Thomas Gleixner <tglx@linutronix.de> > > When a serial port is used for kernel console output, then all > modifications to the UART registers which are done from other contexts, > e.g. getty, termios, are interference points for the kernel console. > > So far this has been ignored and the printk output is based on the > principle of hope. The rework of the console infrastructure which aims to > support threaded and atomic consoles, requires to mark sections which > modify the UART registers as unsafe. This allows the atomic write function > to make informed decisions and eventually to restore operational state. It > also allows to prevent the regular UART code from modifying UART registers > while printk output is in progress. > > All modifications of UART registers are guarded by the UART port lock, > which provides an obvious synchronization point with the console > infrastructure. > > To avoid adding this functionality to all UART drivers, wrap the > spin_[un]lock*() invocations for uart_port::lock into helper functions > which just contain the spin_[un]lock*() invocations for now. In a > subsequent step these helpers will gain the console synchronization > mechanisms. > > Converted with coccinelle. No functional change. > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > --- > drivers/tty/serial/8250/8250_core.c | 12 ++-- > drivers/tty/serial/8250/8250_port.c | 100 ++++++++++++++-------------- > 2 files changed, 56 insertions(+), 56 deletions(-) > @@ -3403,9 +3403,9 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s, > touch_nmi_watchdog(); > > if (oops_in_progress) > - locked = spin_trylock_irqsave(&port->lock, flags); > + locked = uart_port_trylock_irqsave(port, &flags); > else > - spin_lock_irqsave(&port->lock, flags); > + uart_port_lock_irqsave(port, &flags); Not related to any problem (with this patch) but I'm a bit curious is this construct going to remain there after the follow-up work? And there's the similar one in some other drivers (with some variations related to local_irq_save()): if (port->sysrq) { locked = 0; } else if (oops_in_progress) { locked = spin_trylock(&port->lock); } else { spin_lock(&port->lock); locked = 1; }
On 2023-09-15, Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote: >> @@ -3403,9 +3403,9 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s, >> touch_nmi_watchdog(); >> >> if (oops_in_progress) >> - locked = spin_trylock_irqsave(&port->lock, flags); >> + locked = uart_port_trylock_irqsave(port, &flags); >> else >> - spin_lock_irqsave(&port->lock, flags); >> + uart_port_lock_irqsave(port, &flags); > > Not related to any problem (with this patch) but I'm a bit curious is > this construct going to remain there after the follow-up work? Yes. The uart port lock already provides excellent coverage of unsafe regions in uart drivers. We want to take advantage of that. > And there's the similar one in some other drivers (with some > variations related to local_irq_save()): > > if (port->sysrq) { > locked = 0; > } else if (oops_in_progress) { > locked = spin_trylock(&port->lock); > } else { > spin_lock(&port->lock); > locked = 1; > } With the follow-up work we are introducing a new type of console (CON_NBCON) that supports atomic and threaded printing. Current console drivers must be converted if they want these features. When converting a driver to NBCON, such variations as above will need to be addressed. The follow-up work provides new functions and semantics to allow drivers to implement more reliable code than just: "trylock and keep going no matter what". For console drivers that are _not_ converted to NBCON, the uart port lock wrappers will not provide any changed functionality. John Ogness
On Thu, Sep 14 2023 at 20:01, Maciej W. Rozycki wrote: > On Thu, 14 Sep 2023, John Ogness wrote: > >> Patches 2-74 switch all uart port locking call sites to use the new >> wrappers. These patches were automatically generated using coccinelle. > > Hmm, no need to do this for drivers/tty/serial/zs.c? zs.c does not use port lock at all. It has like a couple of other drivers a local homebrewn spinlock. Thanks, tglx
On Fri, 15 Sep 2023, Thomas Gleixner wrote: > >> Patches 2-74 switch all uart port locking call sites to use the new > >> wrappers. These patches were automatically generated using coccinelle. > > > > Hmm, no need to do this for drivers/tty/serial/zs.c? > > zs.c does not use port lock at all. It has like a couple of other > drivers a local homebrewn spinlock. Ah, right, that's because there are registers shared between two ports within one SCC, so the spinlock has to be shared as well. This also indicates that dz.c is wrong and shouldn't be using a per-port spinlock as the DZ has a shared register set between all the four ports (it's a serial line multiplexer rather than a set discrete ports; up to 8 lines are architecturally supported, though we don't have support in Linux for systems having those), e.g. there's only one 16-bit receiver buffer register for all the four ports, supplying the 8-bit character received along with the receive status and the number of the line this data arrived on, and similarly there's only one transmit data register, which supplies data to the next enabled line whose transmit buffer needs servicing, and the chip routes the data itself. Therefore the driver ought to use a shared spinlock too. I guess it wasn't noticed so far because DZ devices aren't that common (and my usual test machine is currently broken too, pending an SRAM chip replacement, hopefully in the next few weeks) and then hardly ever more than one serial line has been used at a time with these devices. It looks like the first issue for me to look into once the machine has been fixed. Maybe dz.c shouldn't be touched by this series then? (Though obviously both drivers will have to be eventually adapted for the ultimate console rework.) Thanks for your input, as it turns out it has had an unexpected outcome. Maciej
On 2023-09-15, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote: > Maybe dz.c shouldn't be touched by this series then? Correct. This series is only wrapping the uart port lock, which dz.c is not using. > Though obviously both drivers will have to be eventually adapted for > the ultimate console rework. Correct. Thanks for clarifying how the hardware works. John
On 2023-09-15, Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote: > Would this also be useful to enable printing to console while under > port's lock (by postponing the output until the lock is released)? > > E.g., 8250_dw.c has had this commented out since the dawn on time: > /* > * FIXME: this deadlocks if port->lock is already held > * dev_err(p->dev, "Couldn't set LCR to %d\n", value); > */ Yes, this will fix such issues. However, only for consoles that are converted to the new NBCON console type. Good news, the 8250 driver will be the flagship driver that is converted as part of the rework. So this particular issue will be solved then. I will try to remember this so that I can remove the FIXME in the series. Thanks for mentioning it. John
On Tue, Sep 19, 2023 at 04:24:48PM +0200, Petr Mladek wrote: > On Thu 2023-09-14 20:43:18, John Ogness wrote: > > From: Thomas Gleixner <tglx@linutronix.de> > > > > When a serial port is used for kernel console output, then all > > modifications to the UART registers which are done from other contexts, > > e.g. getty, termios, are interference points for the kernel console. > > > > So far this has been ignored and the printk output is based on the > > principle of hope. The rework of the console infrastructure which aims to > > support threaded and atomic consoles, requires to mark sections which > > modify the UART registers as unsafe. This allows the atomic write function > > to make informed decisions and eventually to restore operational state. It > > also allows to prevent the regular UART code from modifying UART registers > > while printk output is in progress. > > > > All modifications of UART registers are guarded by the UART port lock, > > which provides an obvious synchronization point with the console > > infrastructure. > > > > Provide wrapper functions for spin_[un]lock*(port->lock) invocations so > > that the console mechanics can be applied later on at a single place and > > does not require to copy the same logic all over the drivers. > > > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > > --- > > include/linux/serial_core.h | 79 +++++++++++++++++++++++++++++++++++++ > > 1 file changed, 79 insertions(+) > > > > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h > > index bb6f073bc159..f1d5c0d1568c 100644 > > --- a/include/linux/serial_core.h > > +++ b/include/linux/serial_core.h > > +/** > > + * uart_port_lock_irqsave - Lock the UART port, save and disable interrupts > > + * @up: Pointer to UART port structure > > + * @flags: Pointer to interrupt flags storage > > + */ > > +static inline void uart_port_lock_irqsave(struct uart_port *up, unsigned long *flags) > > +{ > > + spin_lock_irqsave(&up->lock, *flags); > > +} > > IMHO, it would have been better to pass the flags variable directly > via a macro as it is done in most *_lock_*_irqsafe() APIs. I mean > something like: > > /** > * uart_port_trylock_irqsave - Try to lock the UART port, save and disable interrupts > * @up: Pointer to UART port structure > * @flags: Interrupt flags storage > * > * Returns: True if lock was acquired, false otherwise > */ > #define uart_port_lock_irqsave(up, flags) \ > ({ \ > local_irq_save(flags); \ > uart_port_lock(lock) \ > }) > > > + > > +/** > > + * uart_port_trylock - Try to lock the UART port > > + * @up: Pointer to UART port structure > > + * > > + * Returns: True if lock was acquired, false otherwise > > + */ > > +static inline bool uart_port_trylock(struct uart_port *up) > > +{ > > + return spin_trylock(&up->lock); > > +} > > + > > +/** > > + * uart_port_trylock_irqsave - Try to lock the UART port, save and disable interrupts > > + * @up: Pointer to UART port structure > > + * @flags: Pointer to interrupt flags storage > > + * > > + * Returns: True if lock was acquired, false otherwise > > + */ > > +static inline bool uart_port_trylock_irqsave(struct uart_port *up, unsigned long *flags) > > +{ > > + return spin_trylock_irqsave(&up->lock, *flags); > > +} > > Similar here: > > /** > * uart_port_trylock_irqsave - Try to lock the UART port, save and disable interrupts > * @up: Pointer to UART port structure > * @flags: Interrupt flags storage > * > * Returns: True if lock was acquired, false otherwise > */ > #define uart_port_trylock_irqsave(up, flags) \ > ({ \ > bool __ret; \ > \ > local_irq_save(flags); \ > __ret = uart_port_trylock(lock) \ > if (!__ret) \ > local_irq_restore(flags); \ > __ret; \ > }) What is the difference here of a macro vs. an inline function going to do for the resulting binary? The important thing is now we have wrapper functions, people can tweak them all they want to see if we can get better results :) thanks for the review! greg k-h
On Tue, Sep 19 2023 at 16:24, Petr Mladek wrote: > On Thu 2023-09-14 20:43:18, John Ogness wrote: > IMHO, it would have been better to pass the flags variable directly > via a macro as it is done in most *_lock_*_irqsafe() APIs. I mean > something like: > > /** > * uart_port_trylock_irqsave - Try to lock the UART port, save and disable interrupts > * @up: Pointer to UART port structure > * @flags: Interrupt flags storage > * > * Returns: True if lock was acquired, false otherwise > */ > #define uart_port_lock_irqsave(up, flags) \ > ({ \ > local_irq_save(flags); \ > uart_port_lock(lock) \ > }) It's worse. 1) Macros are not type safe by themself and rely on type safety of the inner workings. 2) Macros are bad for grep as you can't search for a 'struct foo *' argument. Even semantic parsers have their problems with macro constructs. I just learned that again when doing this. 3) Macros are just horrible to read 4) If you want to out of line the wrapper later, then you still have to keep the macro around because the 'flags' argument is by value and not a pointer.