From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Kroah-Hartman Subject: Re: [PATCH] kgdboc: disable the console lock when in kgdb Date: Tue, 30 Jul 2019 17:38:18 +0200 Message-ID: <20190730153818.GA1025@kroah.com> References: <20190725183551.169208-1-dianders@chromium.org> <20190726091630.GA20016@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Doug Anderson Cc: Jason Wessel , Daniel Thompson , Daniel Vetter , Maarten Lankhorst , Sam Ravnborg , Jiri Slaby , kgdb-bugreport@lists.sourceforge.net, LKML , linux-serial@vger.kernel.org List-Id: linux-serial@vger.kernel.org On Fri, Jul 26, 2019 at 09:19:21AM -0700, Doug Anderson wrote: > Hi, > > On Fri, Jul 26, 2019 at 2:16 AM Greg Kroah-Hartman > wrote: > > > > On Thu, Jul 25, 2019 at 11:35:51AM -0700, Douglas Anderson wrote: > > > After commit ddde3c18b700 ("vt: More locking checks") kdb / kgdb has > > > become useless because my console is filled with spews of: > > > > > > WARNING: CPU: 0 PID: 0 at .../drivers/tty/vt/vt.c:3846 con_is_visible+0x50/0x74 > > > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-rc1+ #48 > > > Hardware name: Rockchip (Device Tree) > > > Backtrace: > > > [] (dump_backtrace) from [] (show_stack+0x20/0x24) > > > [] (show_stack) from [] (dump_stack+0xb0/0xd0) > > > [] (dump_stack) from [] (__warn+0xec/0x11c) > > > [] (__warn) from [] (warn_slowpath_null+0x4c/0x58) > > > [] (warn_slowpath_null) from [] (con_is_visible+0x50/0x74) > > > [] (con_is_visible) from [] (con_scroll+0x108/0x1ac) > > > [] (con_scroll) from [] (lf+0x44/0x88) > > > [] (lf) from [] (vt_console_print+0x1a4/0x2bc) > > > [] (vt_console_print) from [] (vkdb_printf+0x420/0x8a4) > > > [] (vkdb_printf) from [] (kdb_printf+0x44/0x60) > > > [] (kdb_printf) from [] (kdb_main_loop+0xf4/0x6e0) > > > [] (kdb_main_loop) from [] (kdb_stub+0x268/0x398) > > > [] (kdb_stub) from [] (kgdb_cpu_enter+0x1f8/0x674) > > > [] (kgdb_cpu_enter) from [] (kgdb_handle_exception+0x1c4/0x1fc) > > > [] (kgdb_handle_exception) from [] (kgdb_compiled_brk_fn+0x30/0x3c) > > > [] (kgdb_compiled_brk_fn) from [] (do_undefinstr+0x180/0x1a0) > > > [] (do_undefinstr) from [] (__und_svc_finish+0x0/0x3c) > > > ... > > > [] (kgdb_breakpoint) from [] (sysrq_handle_dbg+0x58/0x6c) > > > [] (sysrq_handle_dbg) from [] (__handle_sysrq+0xac/0x154) > > > > > > Let's disable this warning when we're in kgdb to avoid the spew. The > > > whole system is stopped when we're in kgdb so we can't exactly wait > > > for someone else to drop the lock. Presumably the best we can do is > > > to disable the warning and hope for the best. > > > > > > Fixes: ddde3c18b700 ("vt: More locking checks") > > > Cc: Daniel Vetter > > > Signed-off-by: Douglas Anderson > > > --- > > > > > > drivers/tty/serial/kgdboc.c | 4 ++++ > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/drivers/tty/serial/kgdboc.c b/drivers/tty/serial/kgdboc.c > > > index bfe5e9e034ec..c7d51b51898f 100644 > > > --- a/drivers/tty/serial/kgdboc.c > > > +++ b/drivers/tty/serial/kgdboc.c > > > @@ -277,10 +277,14 @@ static void kgdboc_pre_exp_handler(void) > > > /* Increment the module count when the debugger is active */ > > > if (!kgdb_connected) > > > try_module_get(THIS_MODULE); > > > + > > > + atomic_inc(&ignore_console_lock_warning); > > > } > > > > > > static void kgdboc_post_exp_handler(void) > > > { > > > + atomic_dec(&ignore_console_lock_warning); > > > + > > > /* decrement the module count when the debugger detaches */ > > > if (!kgdb_connected) > > > module_put(THIS_MODULE); > > > -- > > > 2.22.0.709.g102302147b-goog > > > > I have the following patch in my tree to go to Linus that I think might > > fix this issue for you. Can you test it instead? > > > > thanks, > > > > greg k-h > > > > ----------------- > > > > > > From 61d51456f35760a09e8aa1e6ddd247f1547015d3 Mon Sep 17 00:00:00 2001 > > From: Daniel Vetter > > Date: Thu, 18 Jul 2019 10:09:03 +0200 > > Subject: [PATCH] vt: Grab console_lock around con_is_bound in show_bind > > > > Not really harmful not to, but also not harm in grabbing the lock. And > > this shuts up a new WARNING I introduced in commit ddde3c18b700 ("vt: > > More locking checks"). > > > > Reported-by: Jens Remus > > Cc: linux-kernel@vger.kernel.org > > Cc: dri-devel@lists.freedesktop.org > > Cc: linux-fbdev@vger.kernel.org > > Cc: linux-s390@vger.kernel.org > > Cc: Nicolas Pitre > > Cc: Martin Hostettler > > Cc: Adam Borowski > > Cc: Mikulas Patocka > > Cc: Daniel Vetter > > Cc: Sam Ravnborg > > Fixes: ddde3c18b700 ("vt: More locking checks") > > Signed-off-by: Daniel Vetter > > Tested-by: Jens Remus > > Acked-by: Sam Ravnborg > > Link: https://lore.kernel.org/r/20190718080903.22622-1-daniel.vetter@ffwll.ch > > Signed-off-by: Greg Kroah-Hartman > > --- > > drivers/tty/vt/vt.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c > > index ec92f36ab5c4..34aa39d1aed9 100644 > > --- a/drivers/tty/vt/vt.c > > +++ b/drivers/tty/vt/vt.c > > @@ -3771,7 +3771,11 @@ static ssize_t show_bind(struct device *dev, struct device_attribute *attr, > > char *buf) > > { > > struct con_driver *con = dev_get_drvdata(dev); > > - int bind = con_is_bound(con->con); > > + int bind; > > + > > + console_lock(); > > + bind = con_is_bound(con->con); > > + console_unlock(); > > > > return snprintf(buf, PAGE_SIZE, "%i\n", bind); > > } > > Thanks for checking. I had actually noticed that patch (I searched > the mailing lists for the short git hash of the commit that broke me > and found it) and had decided it wouldn't fix my problems. > Specifically I think it could only possibly fix things if the function > show_bind() was somewhere in my stack trace. ...and it isn't. > > ...but after your message I decided to be extra super sure. I tried: > > 1. Going back to mainline commit 6789f873ed37 ("Merge tag 'pm-5.3-rc2' > of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm") and > picking commit 61d51456f357 ("vt: Grab console_lock around > con_is_bound in show_bind") from linuxnext. It didn't fix my problem. > > 2. Going to next-20190726. It didn't fix my problem. > > ...so indeed my patch addresses a different issue than the one you > pointed to, even if both fix problems introduced by the same commit. Thanks for testing, I'll go queue this up now. greg k-h