On (01/29/16 15:37), Sergey Senozhatsky wrote:
>
> panic()->console_panic_mode()->{for_each_console()->reset(),
> zap_locks()}->console_trelock()->console_unlock().
Hello,
This is not a final submission, just a RFC, so we can settle a better
plan. the patches are not signed off, have known
On (01/29/16 15:37), Sergey Senozhatsky wrote:
>
> panic()->console_panic_mode()->{for_each_console()->reset(),
> zap_locks()}->console_trelock()->console_unlock().
Hello,
This is not a final submission, just a RFC, so we can settle a better
plan. the patches are not signed off, have known
On Fri, Jan 29, 2016 at 01:05:00PM +0900, Sergey Senozhatsky wrote:
> then this will explode:
>
> printk
> spin_lock
> >> coding error <<
> spin_unlock
> printk
>spin_lock
> printk
> spin_lock
> printk
>spin_lock
> ... boom
>
> vprintk_emit() recursion
On Thu, Jan 28, 2016 at 04:15:02PM +0900, Byungchul Park wrote:
> On Wed, Jan 27, 2016 at 02:49:35PM -0800, Peter Hurley wrote:
> > And we already have lockdep turned off to avoid triggering a recursive
> > lockdep report (which I think is a mistake).
>
> Yes, we already have a way to turn off
On Fri, Jan 29, 2016 at 04:13:30PM +0900, Sergey Senozhatsky wrote:
> On (01/29/16 15:54), Byungchul Park wrote:
> > On Fri, Jan 29, 2016 at 09:27:03AM +0900, Sergey Senozhatsky wrote:
> > >
> > > well, the stack is surely limited, but on every
> > > spin_dump()->spin_lock() recursive call it
On Fri, Jan 29, 2016 at 01:05:00PM +0900, Sergey Senozhatsky wrote:
> then this will explode:
>
> printk
> spin_lock
> >> coding error <<
> spin_unlock
> printk
>spin_lock
> printk
> spin_lock
> printk
>spin_lock
> ... boom
>
> vprintk_emit() recursion
On Fri, Jan 29, 2016 at 04:13:30PM +0900, Sergey Senozhatsky wrote:
> On (01/29/16 15:54), Byungchul Park wrote:
> > On Fri, Jan 29, 2016 at 09:27:03AM +0900, Sergey Senozhatsky wrote:
> > >
> > > well, the stack is surely limited, but on every
> > > spin_dump()->spin_lock() recursive call it
On Thu, Jan 28, 2016 at 04:15:02PM +0900, Byungchul Park wrote:
> On Wed, Jan 27, 2016 at 02:49:35PM -0800, Peter Hurley wrote:
> > And we already have lockdep turned off to avoid triggering a recursive
> > lockdep report (which I think is a mistake).
>
> Yes, we already have a way to turn off
On (01/29/16 15:54), Byungchul Park wrote:
> On Fri, Jan 29, 2016 at 09:27:03AM +0900, Sergey Senozhatsky wrote:
> >
> > well, the stack is surely limited, but on every
> > spin_dump()->spin_lock() recursive call it does another
> > round of
> >
> > u64 loops = loops_per_jiffy * HZ;
> >
> >
On Fri, Jan 29, 2016 at 09:27:03AM +0900, Sergey Senozhatsky wrote:
>
> well, the stack is surely limited, but on every
> spin_dump()->spin_lock() recursive call it does another
> round of
>
> u64 loops = loops_per_jiffy * HZ;
>
> for (i = 0; i < loops; i++) {
> if
On (01/29/16 15:16), Sergey Senozhatsky wrote:
>
> http://marc.info/?l=linux-kernel=144976121529901
>
hm... I don't like that patch. ->reset() loop must be done outside
of zap_locks(). we can have a printk() recursion in CPU1, but console
driver lock may be owned by CPU2 in driver's
On (01/28/16 21:48), Peter Hurley wrote:
[..]
> > yes, I proposed to add a ->reset callback to struct console
> > a while ago, and to do a console reset loop in zap_locks()
>
> What was the patch series title? I'd like to review that.
Thanks.
it was deep in the thread where Jan Kara proposed v1
On 01/28/2016 09:28 PM, Sergey Senozhatsky wrote:
> On (01/28/16 20:32), Peter Hurley wrote:
> [..]
>> You're assuming that Byungchul's patch is relevant to the recursion
>> he witnessed. There are several paths into spin_dump().
>
> yes. I was speaking in the context of Byungchul's report.
>
>>
On (01/28/16 20:32), Peter Hurley wrote:
[..]
> You're assuming that Byungchul's patch is relevant to the recursion
> he witnessed. There are several paths into spin_dump().
yes. I was speaking in the context of Byungchul's report.
> Here's one that doesn't wait at all:
>
> vprintk_emit()
>
On 01/28/2016 04:27 PM, Sergey Senozhatsky wrote:
> On (01/28/16 15:08), Peter Hurley wrote:
> [..]
>>> even if at some level of recursion (nested printk calls)
>>> spin_dump()->__spin_lock_debug()->arch_spin_trylock() acquires the
>>> lock, it returns back with the spin lock unlocked anyway.
>>>
On (01/29/16 12:00), Byungchul Park wrote:
[..]
> > it took a while to even find out that you are reporting this issues
> > not against a real H/W, but a qemu. I suppose qemu-arm running on
> > x86_64 box.
>
> No matter what kind of box I used because I only kept talking about the
> possiblity.
On Fri, Jan 29, 2016 at 09:54:06AM +0900, Sergey Senozhatsky wrote:
> because you don't give any details and don't answer any questions.
There are 2 ways to make the kernel better and stabler.
1) Remove the possiblity which make the system go crazy, even though it
would hardly happen since the
On (01/29/16 08:54), Byungchul Park wrote:
> > The problem is you have postulated a very shallow recursion.
> > This looks much worse if this happens 1000 times, and
> > probably won't recover to output anything.
> >
> > Additionally, what if the console_sem is simply corrupted?
> > A livelock
On (01/28/16 15:08), Peter Hurley wrote:
[..]
> > even if at some level of recursion (nested printk calls)
> > spin_dump()->__spin_lock_debug()->arch_spin_trylock() acquires the
> > lock, it returns back with the spin lock unlocked anyway.
> >
> > vprintk_emit()
> > console_trylock()
> >
On Thu, Jan 28, 2016 at 03:08:19PM -0800, Peter Hurley wrote:
> The problem is you have postulated a very shallow recursion.
> This looks much worse if this happens 1000 times, and
> probably won't recover to output anything.
>
> Additionally, what if the console_sem is simply corrupted?
> A
On 01/28/2016 07:42 AM, Sergey Senozhatsky wrote:
> On (01/28/16 19:53), Sergey Senozhatsky wrote:
>>> ah... silly me... you mean the first CPU that triggers the spin_dump() will
>> ^^^ this, of course, is true for
>>
On (01/28/16 19:53), Sergey Senozhatsky wrote:
> > ah... silly me... you mean the first CPU that triggers the spin_dump() will
> ^^^ this, of course, is true for
> console_sem->lock and logbuf_lock
>
two small corrections.
On (01/28/16 19:41), Sergey Senozhatsky wrote:
[..]
> > Unfortunately, it's not reproduced anymore.
> >
> > If it's clearly a spinlock caller's bug as you said, modifying the
> > spinlock debug code does not help it at all. But I found there's a
> > possiblity in the debug
On (01/28/16 17:13), Byungchul Park wrote:
[..]
> > > > int down_trylock(struct semaphore *sem)
> > > > {
> > > > unsigned long flags;
> > > > int count;
> > > >
> > > > raw_spin_lock_irqsave(>lock, flags); << um...
> > >
> > > I also think it's hard, but a
On Thu, Jan 28, 2016 at 03:05:30PM +0900, Sergey Senozhatsky wrote:
> On (01/28/16 13:36), byungchul.park wrote:
> [..]
> > > the thing is, it's really-really hard to lockup in console_trylock()...
> > >
> > > int down_trylock(struct semaphore *sem)
> > > {
> > > unsigned long flags;
> >
On (01/28/16 21:48), Peter Hurley wrote:
[..]
> > yes, I proposed to add a ->reset callback to struct console
> > a while ago, and to do a console reset loop in zap_locks()
>
> What was the patch series title? I'd like to review that.
Thanks.
it was deep in the thread where Jan Kara proposed v1
On (01/29/16 15:54), Byungchul Park wrote:
> On Fri, Jan 29, 2016 at 09:27:03AM +0900, Sergey Senozhatsky wrote:
> >
> > well, the stack is surely limited, but on every
> > spin_dump()->spin_lock() recursive call it does another
> > round of
> >
> > u64 loops = loops_per_jiffy * HZ;
> >
> >
On (01/28/16 19:53), Sergey Senozhatsky wrote:
> > ah... silly me... you mean the first CPU that triggers the spin_dump() will
> ^^^ this, of course, is true for
> console_sem->lock and logbuf_lock
>
On Fri, Jan 29, 2016 at 09:27:03AM +0900, Sergey Senozhatsky wrote:
>
> well, the stack is surely limited, but on every
> spin_dump()->spin_lock() recursive call it does another
> round of
>
> u64 loops = loops_per_jiffy * HZ;
>
> for (i = 0; i < loops; i++) {
> if
On (01/29/16 15:16), Sergey Senozhatsky wrote:
>
> http://marc.info/?l=linux-kernel=144976121529901
>
hm... I don't like that patch. ->reset() loop must be done outside
of zap_locks(). we can have a printk() recursion in CPU1, but console
driver lock may be owned by CPU2 in driver's
On 01/28/2016 07:42 AM, Sergey Senozhatsky wrote:
> On (01/28/16 19:53), Sergey Senozhatsky wrote:
>>> ah... silly me... you mean the first CPU that triggers the spin_dump() will
>> ^^^ this, of course, is true for
>>
On Thu, Jan 28, 2016 at 03:08:19PM -0800, Peter Hurley wrote:
> The problem is you have postulated a very shallow recursion.
> This looks much worse if this happens 1000 times, and
> probably won't recover to output anything.
>
> Additionally, what if the console_sem is simply corrupted?
> A
On (01/28/16 15:08), Peter Hurley wrote:
[..]
> > even if at some level of recursion (nested printk calls)
> > spin_dump()->__spin_lock_debug()->arch_spin_trylock() acquires the
> > lock, it returns back with the spin lock unlocked anyway.
> >
> > vprintk_emit()
> > console_trylock()
> >
On (01/29/16 08:54), Byungchul Park wrote:
> > The problem is you have postulated a very shallow recursion.
> > This looks much worse if this happens 1000 times, and
> > probably won't recover to output anything.
> >
> > Additionally, what if the console_sem is simply corrupted?
> > A livelock
On Thu, Jan 28, 2016 at 03:05:30PM +0900, Sergey Senozhatsky wrote:
> On (01/28/16 13:36), byungchul.park wrote:
> [..]
> > > the thing is, it's really-really hard to lockup in console_trylock()...
> > >
> > > int down_trylock(struct semaphore *sem)
> > > {
> > > unsigned long flags;
> >
On (01/28/16 17:13), Byungchul Park wrote:
[..]
> > > > int down_trylock(struct semaphore *sem)
> > > > {
> > > > unsigned long flags;
> > > > int count;
> > > >
> > > > raw_spin_lock_irqsave(>lock, flags); << um...
> > >
> > > I also think it's hard, but a
two small corrections.
On (01/28/16 19:41), Sergey Senozhatsky wrote:
[..]
> > Unfortunately, it's not reproduced anymore.
> >
> > If it's clearly a spinlock caller's bug as you said, modifying the
> > spinlock debug code does not help it at all. But I found there's a
> > possiblity in the debug
On Fri, Jan 29, 2016 at 09:54:06AM +0900, Sergey Senozhatsky wrote:
> because you don't give any details and don't answer any questions.
There are 2 ways to make the kernel better and stabler.
1) Remove the possiblity which make the system go crazy, even though it
would hardly happen since the
On (01/29/16 12:00), Byungchul Park wrote:
[..]
> > it took a while to even find out that you are reporting this issues
> > not against a real H/W, but a qemu. I suppose qemu-arm running on
> > x86_64 box.
>
> No matter what kind of box I used because I only kept talking about the
> possiblity.
On 01/28/2016 04:27 PM, Sergey Senozhatsky wrote:
> On (01/28/16 15:08), Peter Hurley wrote:
> [..]
>>> even if at some level of recursion (nested printk calls)
>>> spin_dump()->__spin_lock_debug()->arch_spin_trylock() acquires the
>>> lock, it returns back with the spin lock unlocked anyway.
>>>
On (01/28/16 20:32), Peter Hurley wrote:
[..]
> You're assuming that Byungchul's patch is relevant to the recursion
> he witnessed. There are several paths into spin_dump().
yes. I was speaking in the context of Byungchul's report.
> Here's one that doesn't wait at all:
>
> vprintk_emit()
>
On 01/28/2016 09:28 PM, Sergey Senozhatsky wrote:
> On (01/28/16 20:32), Peter Hurley wrote:
> [..]
>> You're assuming that Byungchul's patch is relevant to the recursion
>> he witnessed. There are several paths into spin_dump().
>
> yes. I was speaking in the context of Byungchul's report.
>
>>
On Wed, Jan 27, 2016 at 02:49:35PM -0800, Peter Hurley wrote:
> And we already have lockdep turned off to avoid triggering a recursive
> lockdep report (which I think is a mistake).
Yes, we already have a way to turn off the lock debug so that we can
avoid it. So I used it in v4.
thanks,
On (01/28/16 13:36), byungchul.park wrote:
[..]
> > the thing is, it's really-really hard to lockup in console_trylock()...
> >
> > int down_trylock(struct semaphore *sem)
> > {
> > unsigned long flags;
> > int count;
> >
> > raw_spin_lock_irqsave(>lock, flags); <<
foundation.org; pe...@hurleysoftware.com;
> sergey.senozhatsky.w...@gmail.com; sergey.senozhat...@gmail.com
> Subject: Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in
> the debug code
>
> ok, I'll repeat the questions.
>
> under what circumstances you hit this pr
Hello,
On (01/28/16 10:42), Byungchul Park wrote:
> +cc pe...@hurleysoftware.com
> +cc sergey.senozhatsky.w...@gmail.com
thanks for Cc-ing.
> On Wed, Jan 27, 2016 at 09:01:01PM +0900, Byungchul Park wrote:
> > changes form v3 to v4
> > - reuse a existing code as much as possible for preventing
+cc pe...@hurleysoftware.com
+cc sergey.senozhatsky.w...@gmail.com
On Wed, Jan 27, 2016 at 09:01:01PM +0900, Byungchul Park wrote:
> changes form v3 to v4
> - reuse a existing code as much as possible for preventing an infinite
> recursive cycle.
>
> changes from v2 to v3
> - avoid printk()
On 01/27/2016 04:01 AM, Byungchul Park wrote:
> changes form v3 to v4
> - reuse a existing code as much as possible for preventing an infinite
> recursive cycle.
>
> changes from v2 to v3
> - avoid printk() only in case of lockup suspected, not real lockup in
> which case it does not help at
On 01/27/2016 04:01 AM, Byungchul Park wrote:
> changes form v3 to v4
> - reuse a existing code as much as possible for preventing an infinite
> recursive cycle.
>
> changes from v2 to v3
> - avoid printk() only in case of lockup suspected, not real lockup in
> which case it does not help at
On (01/28/16 13:36), byungchul.park wrote:
[..]
> > the thing is, it's really-really hard to lockup in console_trylock()...
> >
> > int down_trylock(struct semaphore *sem)
> > {
> > unsigned long flags;
> > int count;
> >
> > raw_spin_lock_irqsave(>lock, flags); <<
Hello,
On (01/28/16 10:42), Byungchul Park wrote:
> +cc pe...@hurleysoftware.com
> +cc sergey.senozhatsky.w...@gmail.com
thanks for Cc-ing.
> On Wed, Jan 27, 2016 at 09:01:01PM +0900, Byungchul Park wrote:
> > changes form v3 to v4
> > - reuse a existing code as much as possible for preventing
+cc pe...@hurleysoftware.com
+cc sergey.senozhatsky.w...@gmail.com
On Wed, Jan 27, 2016 at 09:01:01PM +0900, Byungchul Park wrote:
> changes form v3 to v4
> - reuse a existing code as much as possible for preventing an infinite
> recursive cycle.
>
> changes from v2 to v3
> - avoid printk()
On Wed, Jan 27, 2016 at 02:49:35PM -0800, Peter Hurley wrote:
> And we already have lockdep turned off to avoid triggering a recursive
> lockdep report (which I think is a mistake).
Yes, we already have a way to turn off the lock debug so that we can
avoid it. So I used it in v4.
thanks,
foundation.org; pe...@hurleysoftware.com;
> sergey.senozhatsky.w...@gmail.com; sergey.senozhat...@gmail.com
> Subject: Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in
> the debug code
>
> ok, I'll repeat the questions.
>
> under what circumstances you hit this pr
54 matches
Mail list logo
