Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1360414
| From | "byungchul.park" <byungchul.park@lge.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | RE: [RFC][PATCH v4 1/2] printk: Make printk() completely async |
| Date | 2016-03-18 09:30 +0100 |
| Message-ID | <rdXXb-33g-1@gated-at.bofh.it> (permalink) |
| References | (6 earlier) <rdex4-5QB-5@gated-at.bofh.it> <rdh1T-7IW-5@gated-at.bofh.it> <rdu8P-8hX-19@gated-at.bofh.it> <rdVsl-1kZ-7@gated-at.bofh.it> <rdWRs-2n2-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
> [..]
> > 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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC][PATCH v4 0/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-03-14 15:20 +0100
[RFC][PATCH v4 1/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-03-14 15:20 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Jan Kara <jack@suse.cz> - 2016-03-15 11:10 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-03-15 15:20 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Byungchul Park <byungchul.park@lge.com> - 2016-03-16 06:50 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-16 08:00 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Byungchul Park <byungchul.park@lge.com> - 2016-03-16 08:40 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-16 09:00 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Byungchul Park <byungchul.park@lge.com> - 2016-03-16 11:40 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-17 01:40 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Byungchul Park <byungchul.park@lge.com> - 2016-03-18 06:50 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-18 08:20 +0100
RE: [RFC][PATCH v4 1/2] printk: Make printk() completely async "byungchul.park" <byungchul.park@lge.com> - 2016-03-18 09:30 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Byungchul Park <byungchul.park@lge.com> - 2016-03-16 08:10 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-16 08:10 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Petr Mladek <pmladek@suse.com> - 2016-03-15 17:00 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-16 03:10 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Byungchul Park <byungchul.park@lge.com> - 2016-03-16 03:20 +0100
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-16 03:40 +0100
[RFC][PATCH v4 2/2] printk: Skip messages on oops Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-03-14 15:20 +0100
Re: [RFC][PATCH v4 2/2] printk: Skip messages on oops Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-17 12:00 +0100
csiph-web