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


Groups > linux.kernel > #1360414

RE: [RFC][PATCH v4 1/2] printk: Make printk() completely async

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

Show all headers | View raw


> [..]
> > 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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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