Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1322776

Re: [PATCH v5] lib/spinlock_debug.c: prevent a recursive cycle in the debug code

From Byungchul Park <byungchul.park@lge.com>
Newsgroups linux.kernel
Subject Re: [PATCH v5] lib/spinlock_debug.c: prevent a recursive cycle in the debug code
Date 2016-02-01 02:50 +0100
Message-ID <qXbMR-3Fa-7@gated-at.bofh.it> (permalink)
References <qWgEW-33T-3@gated-at.bofh.it> <qWgOC-3ad-9@gated-at.bofh.it> <qWZsm-3hB-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Sun, Jan 31, 2016 at 09:40:08PM +0900, Sergey Senozhatsky wrote:
> On (01/29/16 21:54), Byungchul Park wrote:
> > Hello, Andrew
> > 
> > Please take this v5 patch instead of v2 patch, which you took. Or give your
> > opinion.
> > 
> > > It causes an infinite recursive cycle when using CONFIG_DEBUG_SPINLOCK,
> > > in the spin_dump(). Backtrace prints printk() -> console_trylock() ->
> > > do_raw_spin_lock() -> spin_dump() -> printk()... infinitely.
> > > 
> > > When the spin_dump() is called from printk(), we should prevent the
> > > debug spinlock code from calling printk() again in that context. It's
> > > reasonable to avoid printing "lockup suspected" which is just a warning
> > > message but it would cause a real lockup definitely.
> 
> 
> Hello Byungchul,
> 
> thanks for the patch and thanks for bringing this topic to discussion.
> let's not rush, if you don't mind, and return back for a bit. there are
> some serious cases (when we really would want to see a spin_dump output)
> that are broken.

Hello Sergey,

I reviewed your patch, and I hope your proposal to be merged so that the
problematic recursive cycle of printk() can be handled properly e.g. by
panic(). But avoiding an unnecessary recursive cycle is better than
panic(). What I handled in this patch is the warning case which causes
unnecessary lockup and don't need to happen. I think reseting lock or
zapping lock to print a kind of warning is not a good option, even though
your suggestion looks good in the unavoidable lockup case.

Thanks,
Byungchul

> 
> 	-ss

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v5] lib/spinlock_debug.c: prevent a recursive cycle in the debug code Byungchul Park <byungchul.park@lge.com> - 2016-01-29 13:50 +0100
  Re: [PATCH v5] lib/spinlock_debug.c: prevent a recursive cycle in  the debug code Byungchul Park <byungchul.park@lge.com> - 2016-01-29 14:00 +0100
    Re: [PATCH v5] lib/spinlock_debug.c: prevent a recursive cycle in  the debug code Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-01-31 13:40 +0100
      Re: [PATCH v5] lib/spinlock_debug.c: prevent a recursive cycle in  the debug code Byungchul Park <byungchul.park@lge.com> - 2016-02-01 02:50 +0100
        Re: [PATCH v5] lib/spinlock_debug.c: prevent a recursive cycle in  the debug code Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-02-01 03:20 +0100
  Re: [PATCH v5] lib/spinlock_debug.c: prevent a recursive cycle in  the debug code Ingo Molnar <mingo@kernel.org> - 2016-01-30 10:30 +0100
    Re: [PATCH v5] lib/spinlock_debug.c: prevent a recursive cycle in  the debug code Byungchul Park <byungchul.park@lge.com> - 2016-02-02 03:40 +0100
  Re: [PATCH v5] lib/spinlock_debug.c: prevent a recursive cycle in  the debug code Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-02-01 03:40 +0100
    Re: [PATCH v5] lib/spinlock_debug.c: prevent a recursive cycle in  the debug code Byungchul Park <byungchul.park@lge.com> - 2016-02-01 07:30 +0100

csiph-web