This series fixes a silent regression where a SysRq character entered as
BREAK + key on the serial console is consumed by the kernel but never
dispatched to handle_sysrq(). Same description as v1 [1].

v1 -> v2 (per Ilpo's review [2]):

 - Renamed the new lock guard from uart_port_lock_sysrq_irqsave to
   uart_port_lock_check_sysrq_irqsave, preserving the "check" semantics
   of the destructor's underlying helper
   uart_unlock_and_check_sysrq_irqrestore(). Mechanical rename across
   patches 2/3 and 3/3; Ilpo's Reviewed-by trailers from v1 carried
   forward.

 - Patch 1/3 commit message reflowed: the "guard(...)" form is spelled
   out, the "lock side is identical" sentence moved up next to the
   variant introduction, the now-redundant naming-rationale sentence
   removed, and "opt in by using" tightened to "must use".

 - Added Cc: stable@vger.kernel.org to patch 1/3 (prerequisite for the
   stable backport of 2/3 and 3/3); no Fixes: tag, since 1/3 adds new
   API rather than fixing existing code.

 - Collapsed the DEFINE_LOCK_GUARD_1 destructor expression to a single
   line, which fits within the expected indentation.

No re-test of the BREAK + 'h' path was performed for v2 since the
diff against v1 is purely a textual rename plus the commit-message
reflow above; the v1 RTL8196E validation (BREAK + 'h' on the console
UART producing the SysRq help dump, brk counter incrementing in
/proc/tty/driver/serial) continues to apply unchanged. Built and
booted on tty-next (base 16e95bfb79b5).

[1] https://lore.kernel.org/linux-serial/cover.1778592805.git.jnilo@free.fr/
[2] https://lore.kernel.org/linux-serial/3439217b-90b5-5d21-e777-d238b3ffc1a0@linux.intel.com/

Jacques Nilo (3):
  serial: core: introduce guard(uart_port_lock_check_sysrq_irqsave)
  serial: 8250: dispatch SysRq character in serial8250_handle_irq()
  serial: 8250_dw: dispatch SysRq character in dw8250_handle_irq()

 drivers/tty/serial/8250/8250_dw.c   |  2 +-
 drivers/tty/serial/8250/8250_port.c |  7 +++++--
 include/linux/serial_core.h         | 12 ++++++++++++
 3 files changed, 18 insertions(+), 3 deletions(-)


base-commit: 16e95bfb79b5d9d01dc7651d98caf3c2ace331cd
-- 
2.43.0

On Wed, 13 May 2026, Jacques Nilo wrote:

> This series fixes a silent regression where a SysRq character entered as
> BREAK + key on the serial console is consumed by the kernel but never
> dispatched to handle_sysrq(). Same description as v1 [1].

 Thanks for the report and working on a fix.  This issue hit me hard last 
week when chasing a bug with one of my systems where my debug hacks caused 
me to become unable to become root and reboot the system properly.  To my 
surprise I was unable to access any of the magic SysRq features either and 
consequently I had to power-cycle the system remotely via a PDU (it's some 
1600km/1000mi away).  I've now verified that 1/3 and 2/3 bring the feature 
back with patched 7.0.0 and said x86 PC.  No way to verify 3/3 though.

  Maciej

On Wed, May 13, 2026 at 03:30:22PM +0200, Jacques Nilo wrote:
> This series fixes a silent regression where a SysRq character entered as
> BREAK + key on the serial console is consumed by the kernel but never
> dispatched to handle_sysrq(). Same description as v1 [1].

I have read the v1 discussion and v2 makes sense to me and looks good
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

-- 
With Best Regards,
Andy Shevchenko