From: "byungchul.park" <byungchul.park@lge.com>
To: "'Sergey Senozhatsky'" <sergey.senozhatsky.work@gmail.com>
Cc: "'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 17:23:38 +0900 [thread overview]
Message-ID: <002701d180ef$78bff480$6a3fdd80$@lge.com> (raw)
In-Reply-To: <20160318071130.GA19655@swordfish>
> [..]
> > 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 don't think so. It can have chances to survive on SMP with 2 different
locks. Remind the condition this problem can happen.
1. when it is "lockup suspected".
2. when it is within a printk().
2 different locks mean 2 different timing. Therefore it's important to
prevent a recursion at a place trying to obtain the lock. After a lock
is solved, the other lock can be solved step by step.
> I'd really prefer not to mix-in spin_dump/printk recursion problems into
> this
I didn't mix-in it into this. I only focused your patch. Your approach
introduces unnecessary losing a message which we don't want. But you
worried about "infinite recursion" when implementing it without losing
the message. That's why I am saying it doesn't need to be worried and
there's another way, that is, my suggestion.
> patch set. it makes sense not to make printk recursion detection worse due
> to
It makes more sense not to introduce newly added spin_locks. You are
currently utilize the last resort for detecting recursion. It's too bad.
Don't you think so?
> newly added spin_locks to vprintk_emit(), but that's it. this patch set
> set is
> fixing other things in the first place.
As I said, this patch's trying to fix a problem in your patch, which
is introduced while discussing yours.
Thanks,
Byungchul
next prev parent reply other threads:[~2016-03-18 8:23 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
2016-03-18 8:23 ` byungchul.park [this message]
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='002701d180ef$78bff480$6a3fdd80$@lge.com' \
--to=byungchul.park@lge.com \
--cc=akpm@linux-foundation.org \
--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.work@gmail.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.