diff mbox series

[printk,v2,1/5] kdb: do not assume write() callback available

Message ID 20230710134524.25232-2-john.ogness@linutronix.de
State New
Headers
Series various cleanups |

Commit Message

John Ogness July 10, 2023, 1:45 p.m. UTC 
  It is allowed for consoles to provide no write() callback. For
example ttynull does this.

Check if a write() callback is available before using it.

Signed-off-by: John Ogness <john.ogness@linutronix.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
---
 kernel/debug/kdb/kdb_io.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Sergey Senozhatsky July 11, 2023, 12:25 a.m. UTC | #1 
On (23/07/10 15:51), John Ogness wrote:
> It is allowed for consoles to provide no write() callback. For
> example ttynull does this.
> 
> Check if a write() callback is available before using it.
> 
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>

Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Daniel Thompson July 11, 2023, 8:23 a.m. UTC | #2 
On Mon, Jul 10, 2023 at 03:51:20PM +0206, John Ogness wrote:
> It is allowed for consoles to provide no write() callback. For
> example ttynull does this.
>
> Check if a write() callback is available before using it.
>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>

For v1 I shared an ack rather than queuing the patch. Although reading
the thread back it is possible that was based on a misunderstanding
(https://lore.kernel.org/lkml/20230309113020.GA78621@aspen.lan/ ).

Anyhow, it looks like you have designed the new series to be picked
individually?


Daniel.
John Ogness July 11, 2023, 8:58 a.m. UTC | #3 
On 2023-07-11, Daniel Thompson <daniel.thompson@linaro.org> wrote:
> For v1 I shared an ack rather than queuing the patch. Although reading
> the thread back it is possible that was based on a misunderstanding
> (https://lore.kernel.org/lkml/20230309113020.GA78621@aspen.lan/ ).
>
> Anyhow, it looks like you have designed the new series to be picked
> individually?

I understood that Petr will carry the patch. Yes, this series only
includes the non-atomic/non-threaded cleanups so that it will be easier
for Petr to send the full series off to linux-next.

For this patch there is nothing left to do. I should have removed the
kdb people/lists from the mailing. Sorry about that.

John Ogness
Daniel Thompson July 11, 2023, 9:01 a.m. UTC | #4 
On Tue, Jul 11, 2023 at 11:04:11AM +0206, John Ogness wrote:
> On 2023-07-11, Daniel Thompson <daniel.thompson@linaro.org> wrote:
> > For v1 I shared an ack rather than queuing the patch. Although reading
> > the thread back it is possible that was based on a misunderstanding
> > (https://lore.kernel.org/lkml/20230309113020.GA78621@aspen.lan/ ).
> >
> > Anyhow, it looks like you have designed the new series to be picked
> > individually?
>
> I understood that Petr will carry the patch. Yes, this series only
> includes the non-atomic/non-threaded cleanups so that it will be easier
> for Petr to send the full series off to linux-next.

No worries, that's fine for me and from my point-of-view its still:
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>


> For this patch there is nothing left to do. I should have removed the
> kdb people/lists from the mailing. Sorry about that.

To be honest I'd rather be in the loop than out (and with that title my
mail filters would jump in it anyway).


Daniel.
diff mbox series

Patch

diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index 5c7e9ba7cd6b..e9139dfc1f0a 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -576,6 +576,8 @@  static void kdb_msg_write(const char *msg, int msg_len)
 			continue;
 		if (c == dbg_io_ops->cons)
 			continue;
+		if (!c->write)
+			continue;
 		/*
 		 * Set oops_in_progress to encourage the console drivers to
 		 * disregard their internal spin locks: in the current calling