From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Qian Cai <cai@lca.pw>, Steven Rostedt <rostedt@goodmis.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Michal Hocko <mhocko@kernel.org>,
Eric Dumazet <eric.dumazet@gmail.com>,
davem@davemloft.net, netdev@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net/skbuff: silence warnings under memory pressure
Date: Tue, 19 Nov 2019 10:41:34 +0100 [thread overview]
Message-ID: <20191119094134.6hzbjc7l5ite6bpg@pathway.suse.cz> (raw)
In-Reply-To: <20191119004119.GC208047@google.com>
On Tue 2019-11-19 09:41:19, Sergey Senozhatsky wrote:
> On (19/11/18 16:27), Petr Mladek wrote:
> > > > @@ -2027,8 +2027,11 @@ asmlinkage int vprintk_emit(int facility, int level,
> > > > pending_output = (curr_log_seq != log_next_seq);
> > > > logbuf_unlock_irqrestore(flags);
> > > >
> > > > + if (!pending_output)
> > > > + return printed_len;
> > > > +
> > > > /* If called from the scheduler, we can not call up(). */
> > > > - if (!in_sched && pending_output) {
> > > > + if (!in_sched) {
> > > > /*
> > > > * Disable preemption to avoid being preempted while holding
> > > > * console_sem which would prevent anyone from printing to
> > > > @@ -2043,10 +2046,11 @@ asmlinkage int vprintk_emit(int facility, int level,
> > > > if (console_trylock_spinning())
> > > > console_unlock();
> > > > preempt_enable();
> > > > - }
> > > >
> > > > - if (pending_output)
> > > > + wake_up_interruptible(&log_wait);
> >
> > I do not like this. As a result, normal printk() will always deadlock
> > in the scheduler code, including WARN() calls. The chance of the
> > deadlock is small now. It happens only when there is another
> > process waiting for console_sem.
>
> Why would it *always* deadlock? If this is the case, why we don't *always*
> deadlock doing the very same wake_up_process() from console_unlock()?
I speak about _normal_ printk() and not about printk_deferred().
wake_up_process() is called in console_unlock() only when
sem->wait_list is not empty, see up() in kernel/locking/semaphore.c.
printk() itself uses console_trylock() and does not wait.
I believe that this is the rason why printk_sched() was added
so late in 2012. It was more than 10 years after adding
the semaphore into console_unlock(). IMHO, the deadlock
was rare. Of course, it was also hard to debug but it
would not take 10 years.
Best Regards,
Petr
next prev parent reply other threads:[~2019-11-19 9:41 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-30 14:57 [PATCH] net/skbuff: silence warnings under memory pressure Qian Cai
2019-08-30 15:11 ` Eric Dumazet
2019-08-30 15:25 ` Qian Cai
2019-08-30 16:15 ` Eric Dumazet
2019-08-30 18:06 ` Qian Cai
2019-09-03 13:22 ` Michal Hocko
2019-09-03 15:42 ` Qian Cai
2019-09-03 18:53 ` Michal Hocko
2019-09-03 21:42 ` Qian Cai
2019-09-04 6:15 ` Michal Hocko
2019-09-04 6:41 ` Sergey Senozhatsky
2019-09-04 6:54 ` Michal Hocko
2019-09-04 7:19 ` Sergey Senozhatsky
2019-09-04 7:43 ` Sergey Senozhatsky
2019-09-04 12:14 ` Qian Cai
2019-09-04 14:48 ` Sergey Senozhatsky
2019-09-04 15:07 ` Qian Cai
2019-09-04 20:42 ` Qian Cai
2019-09-05 8:32 ` Eric Dumazet
2019-09-05 14:09 ` Qian Cai
2019-09-05 15:06 ` Eric Dumazet
2019-09-05 15:14 ` Eric Dumazet
2019-09-05 11:32 ` Sergey Senozhatsky
2019-09-05 16:03 ` Qian Cai
2019-09-05 17:14 ` Steven Rostedt
2019-09-06 2:50 ` Sergey Senozhatsky
2019-09-06 4:32 ` Sergey Senozhatsky
2019-09-06 21:17 ` Qian Cai
2019-09-05 17:23 ` Steven Rostedt
2019-09-06 3:39 ` Sergey Senozhatsky
2019-09-06 15:32 ` Petr Mladek
2019-09-09 1:10 ` Sergey Senozhatsky
2019-09-06 14:55 ` Petr Mladek
2019-09-06 19:51 ` Sergey Senozhatsky
2019-11-14 17:12 ` Qian Cai
2019-11-18 15:27 ` Petr Mladek
2019-11-19 0:41 ` Sergey Senozhatsky
2019-11-19 9:41 ` Petr Mladek [this message]
2019-11-19 15:58 ` Qian Cai
2019-11-20 1:30 ` Sergey Senozhatsky
2019-11-20 16:13 ` Petr Mladek
2019-11-21 1:05 ` Sergey Senozhatsky
2019-11-21 9:15 ` Petr Mladek
2019-09-04 7:00 ` Sergey Senozhatsky
2019-09-04 8:25 ` Michal Hocko
2019-09-04 11:59 ` Qian Cai
2019-09-04 12:07 ` Michal Hocko
2019-09-04 12:28 ` Qian Cai
2019-09-07 11:00 ` Tetsuo Handa
2019-09-04 6:15 ` Michal Hocko
2019-09-02 14:24 ` Vlastimil Babka
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=20191119094134.6hzbjc7l5ite6bpg@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=cai@lca.pw \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).