linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH] printk/nbcon: Restore IRQ in atomic flush after each emitted record
       [not found] <20251202135832.156559-1-pmladek@suse.com>
@ 2025-12-02 14:33 ` John Ogness
  2025-12-02 16:26   ` Leo Yan
  0 siblings, 1 reply; 4+ messages in thread
From: John Ogness @ 2025-12-02 14:33 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Sergey Senozhatsky, Steven Rostedt, Breno Leitao, linux, paulmck,
	usamaarif642, leo.yan, linux-arm-kernel, linux-kernel,
	kernel-team, rmikey, Petr Mladek

On 2025-12-02, Petr Mladek <pmladek@suse.com> wrote:
> diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
> index 3fa403f9831f..6b8becb6ecd9 100644
> --- a/kernel/printk/nbcon.c
> +++ b/kernel/printk/nbcon.c
> @@ -1549,6 +1549,7 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
>  {
>  	struct nbcon_write_context wctxt = { };
>  	struct nbcon_context *ctxt = &ACCESS_PRIVATE(&wctxt, ctxt);
> +	unsigned long flags;
>  	int err = 0;
>  
>  	ctxt->console			= con;
> @@ -1557,18 +1558,31 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
>  	ctxt->allow_unsafe_takeover	= nbcon_allow_unsafe_takeover();
>  
>  	while (nbcon_seq_read(con) < stop_seq) {
> -		if (!nbcon_context_try_acquire(ctxt, false))
> +		/*
> +		 * Atomic flushing does not use console driver synchronization
> +		 * (i.e. it does not hold the port lock for uart consoles).
> +		 * Therefore IRQs must be disabled to avoid being interrupted
> +		 * and then calling into a driver that will deadlock trying
> +		 * to acquire console ownership.
> +		 */
> +		local_irq_save(flags);
> +		if (!nbcon_context_try_acquire(ctxt, false)) {
> +			local_irq_restore(flags);
>  			return -EPERM;
> +		}
>  
>  		/*
>  		 * nbcon_emit_next_record() returns false when the console was
>  		 * handed over or taken over. In both cases the context is no
>  		 * longer valid.
>  		 */
> -		if (!nbcon_emit_next_record(&wctxt, true))
> +		if (!nbcon_emit_next_record(&wctxt, true)) {
> +			local_irq_restore(flags);
>  			return -EAGAIN;
> +		}
>  
>  		nbcon_context_release(ctxt);
> +		local_irq_restore(flags);


I am not really happy about all the local_irq_restore() usage. Using
guard syntax would be nice here, but AFAICT there is no guard for
local_irq_save()/_restore(). :-/ And I could not come up with any other
alternative that looked more elegant. So let's just keep it this way.

Reviewed-by: John Ogness <john.ogness@linutronix.de>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] printk/nbcon: Restore IRQ in atomic flush after each emitted record
  2025-12-02 14:33 ` [PATCH] printk/nbcon: Restore IRQ in atomic flush after each emitted record John Ogness
@ 2025-12-02 16:26   ` Leo Yan
  2025-12-03 12:27     ` John Ogness
  0 siblings, 1 reply; 4+ messages in thread
From: Leo Yan @ 2025-12-02 16:26 UTC (permalink / raw)
  To: John Ogness
  Cc: Petr Mladek, Sergey Senozhatsky, Steven Rostedt, Breno Leitao,
	linux, paulmck, usamaarif642, linux-arm-kernel, linux-kernel,
	kernel-team, rmikey

On Tue, Dec 02, 2025 at 03:39:54PM +0106, John Ogness wrote:

[...]

> I am not really happy about all the local_irq_restore() usage. Using
> guard syntax would be nice here, but AFAICT there is no guard for
> local_irq_save()/_restore().

Sorry for suddenly jumping in.  Wouldn't guard(irqsave)() be helpful
here?


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] printk/nbcon: Restore IRQ in atomic flush after each emitted record
  2025-12-02 16:26   ` Leo Yan
@ 2025-12-03 12:27     ` John Ogness
  2025-12-04 10:20       ` Petr Mladek
  0 siblings, 1 reply; 4+ messages in thread
From: John Ogness @ 2025-12-03 12:27 UTC (permalink / raw)
  To: Leo Yan
  Cc: Petr Mladek, Sergey Senozhatsky, Steven Rostedt, Breno Leitao,
	linux, paulmck, usamaarif642, linux-arm-kernel, linux-kernel,
	kernel-team, rmikey

On 2025-12-02, Leo Yan <leo.yan@arm.com> wrote:
>> I am not really happy about all the local_irq_restore() usage. Using
>> guard syntax would be nice here, but AFAICT there is no guard for
>> local_irq_save()/_restore().
>
> Sorry for suddenly jumping in.  Wouldn't guard(irqsave)() be helpful
> here?

Thanks, I was not aware of the irqsave variant. We would want the scoped
version. So something like this?

$ git diff -w
diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
index 3fa403f9831f..55beb64c4f4a 100644
--- a/kernel/printk/nbcon.c
+++ b/kernel/printk/nbcon.c
@@ -1557,6 +1557,14 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
 	ctxt->allow_unsafe_takeover	= nbcon_allow_unsafe_takeover();
 
 	while (nbcon_seq_read(con) < stop_seq) {
+		/*
+		 * Atomic flushing does not use console driver synchronization
+		 * (i.e. it does not hold the port lock for uart consoles).
+		 * Therefore IRQs must be disabled to avoid being interrupted
+		 * and then calling into a driver that will deadlock trying
+		 * to acquire console ownership.
+		 */
+		scoped_guard(irqsave) {
 			if (!nbcon_context_try_acquire(ctxt, false))
 				return -EPERM;
 
@@ -1569,6 +1577,7 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
 				return -EAGAIN;
 
 			nbcon_context_release(ctxt);
+		}
 
 		if (!ctxt->backlog) {
 			/* Are there reserved but not yet finalized records? */

John


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] printk/nbcon: Restore IRQ in atomic flush after each emitted record
  2025-12-03 12:27     ` John Ogness
@ 2025-12-04 10:20       ` Petr Mladek
  0 siblings, 0 replies; 4+ messages in thread
From: Petr Mladek @ 2025-12-04 10:20 UTC (permalink / raw)
  To: John Ogness
  Cc: Leo Yan, Sergey Senozhatsky, Steven Rostedt, Breno Leitao, linux,
	paulmck, usamaarif642, linux-arm-kernel, linux-kernel,
	kernel-team, rmikey

On Wed 2025-12-03 13:33:38, John Ogness wrote:
> On 2025-12-02, Leo Yan <leo.yan@arm.com> wrote:
> >> I am not really happy about all the local_irq_restore() usage. Using
> >> guard syntax would be nice here, but AFAICT there is no guard for
> >> local_irq_save()/_restore().
> >
> > Sorry for suddenly jumping in.  Wouldn't guard(irqsave)() be helpful
> > here?
> 
> Thanks, I was not aware of the irqsave variant. We would want the scoped
> version. So something like this?
> 
> $ git diff -w
> diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
> index 3fa403f9831f..55beb64c4f4a 100644
> --- a/kernel/printk/nbcon.c
> +++ b/kernel/printk/nbcon.c
> @@ -1557,6 +1557,14 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
>  	ctxt->allow_unsafe_takeover	= nbcon_allow_unsafe_takeover();
>  
>  	while (nbcon_seq_read(con) < stop_seq) {
> +		/*
> +		 * Atomic flushing does not use console driver synchronization
> +		 * (i.e. it does not hold the port lock for uart consoles).
> +		 * Therefore IRQs must be disabled to avoid being interrupted
> +		 * and then calling into a driver that will deadlock trying
> +		 * to acquire console ownership.
> +		 */
> +		scoped_guard(irqsave) {
>  			if (!nbcon_context_try_acquire(ctxt, false))
>  				return -EPERM;
>  
> @@ -1569,6 +1577,7 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
>  				return -EAGAIN;
>  
>  			nbcon_context_release(ctxt);
> +		}
>  
>  		if (!ctxt->backlog) {
>  			/* Are there reserved but not yet finalized records? */
> 

Great. Thanks for hint. I am going to send v2 with this change.

Best Regards,
Petr


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-12-04 10:20 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20251202135832.156559-1-pmladek@suse.com>
2025-12-02 14:33 ` [PATCH] printk/nbcon: Restore IRQ in atomic flush after each emitted record John Ogness
2025-12-02 16:26   ` Leo Yan
2025-12-03 12:27     ` John Ogness
2025-12-04 10:20       ` Petr Mladek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).