From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Byungchul Park <byungchul.park@lge.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.com>, Petr Mladek <pmladek@suse.com>,
Tejun Heo <tj@kernel.org>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async
Date: Fri, 18 Mar 2016 16:11:30 +0900 [thread overview]
Message-ID: <20160318071130.GA19655@swordfish> (raw)
In-Reply-To: <20160318054913.GN5220@X58A-UD3R>
On (03/18/16 14:49), Byungchul Park wrote:
[..]
> > http://marc.info/?l=linux-kernel&m=145750373530161
>
> I checked it now. Do you mean the wake_up_process() introduced in the new
> patch in console_unlock()? If so, I also think it does not make a deadlock,
> just can make a recursion in the worst case. I thought it was the
> wake_up_process() in up() which is eventually called from console_unlock().
> A deadlock can happen with the wake_up_proces() in up(). :-)
I'm not addressing already existing problems here. I'm trying to
minimise the impact of new code only.
[..]
> diff --git a/kernel/locking/spinlock_debug.c b/kernel/locking/spinlock_debug.c
> index fd24588..30559c6 100644
> --- a/kernel/locking/spinlock_debug.c
> +++ b/kernel/locking/spinlock_debug.c
> @@ -138,14 +138,25 @@ static void __spin_lock_debug(raw_spinlock_t *lock)
> {
> u64 i;
> u64 loops = loops_per_jiffy * HZ;
> + static raw_spinlock_t *suspected_lock = NULL;
this has no chances to survive on SMP systems that have spin_lockup-ed on at
least two different spin locks.
I'd really prefer not to mix-in spin_dump/printk recursion problems into this
patch set. it makes sense not to make printk recursion detection worse due to
newly added spin_locks to vprintk_emit(), but that's it. this patch set set is
fixing other things in the first place.
-ss
> for (i = 0; i < loops; i++) {
> if (arch_spin_trylock(&lock->raw_lock))
> return;
> __delay(1);
> }
> - /* lockup suspected: */
> - spin_dump(lock, "lockup suspected");
> +
> + /*
> + * When we suspect a lockup, it's good enough to inform it once for
> + * the same lock. Otherwise it could cause an infinite recursion if
> + * it's within printk().
> + */
> + if (suspected_lock != lock) {
> + suspected_lock = lock;
> + /* lockup suspected: */
> + spin_dump(lock, "lockup suspected");
> + suspected_lock = NULL;
> + }
> #ifdef CONFIG_SMP
> trigger_all_cpu_backtrace();
> #endif
> --
> 1.9.1
>
next prev parent reply other threads:[~2016-03-18 7:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-14 14:13 [RFC][PATCH v4 0/2] printk: Make printk() completely async Sergey Senozhatsky
2016-03-14 14:13 ` [RFC][PATCH v4 1/2] " Sergey Senozhatsky
2016-03-15 10:03 ` Jan Kara
2016-03-15 14:07 ` Sergey Senozhatsky
2016-03-16 5:39 ` Byungchul Park
2016-03-16 6:58 ` Sergey Senozhatsky
2016-03-16 7:30 ` Byungchul Park
2016-03-16 7:56 ` Sergey Senozhatsky
2016-03-16 10:34 ` Byungchul Park
2016-03-17 0:34 ` Sergey Senozhatsky
2016-03-18 5:49 ` Byungchul Park
2016-03-18 7:11 ` Sergey Senozhatsky [this message]
2016-03-18 8:23 ` byungchul.park
2016-03-16 7:00 ` Byungchul Park
2016-03-16 7:07 ` Sergey Senozhatsky
2016-03-15 15:58 ` Petr Mladek
2016-03-16 2:01 ` Sergey Senozhatsky
2016-03-16 2:10 ` Byungchul Park
2016-03-16 2:31 ` Sergey Senozhatsky
2016-03-14 14:13 ` [RFC][PATCH v4 2/2] printk: Skip messages on oops Sergey Senozhatsky
2016-03-17 10:56 ` Sergey Senozhatsky
2016-04-23 19:36 ` [RFC][PATCH v4 0/2] printk: Make printk() completely async Pavel Machek
2016-04-24 5:03 ` Sergey Senozhatsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160318071130.GA19655@swordfish \
--to=sergey.senozhatsky.work@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=byungchul.park@lge.com \
--cc=jack@suse.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=pmladek@suse.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.