linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Qian Cai <cai@lca.pw>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	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: Mon, 18 Nov 2019 16:27:38 +0100	[thread overview]
Message-ID: <20191118152738.az364dczadskgimc@pathway.suse.cz> (raw)
In-Reply-To: <1573751570.5937.122.camel@lca.pw>

On Thu 2019-11-14 12:12:50, Qian Cai wrote:
> On Thu, 2019-09-05 at 20:32 +0900, Sergey Senozhatsky wrote:
> > On (09/04/19 16:42), Qian Cai wrote:
> > > > Let me think more.
> > > 
> > > To summary, those look to me are all good long-term improvement that would
> > > reduce the likelihood of this kind of livelock in general especially for other
> > > unknown allocations that happen while processing softirqs, but it is still up to
> > > the air if it fixes it 100% in all situations as printk() is going to take more
> > > time
> > 
> > Well. So. I guess that we don't need irq_work most of the time.
> > 
> > We need to queue irq_work for "safe" wake_up_interruptible(), when we
> > know that we can deadlock in scheduler. IOW, only when we are invoked
> > from the scheduler. Scheduler has printk_deferred(), which tells printk()
> > that it cannot do wake_up_interruptible(). Otherwise we can just use
> > normal wake_up_process() and don't need that irq_work->wake_up_interruptible()
> > indirection. The parts of the scheduler, which by mistake call plain printk()
> > from under pi_lock or rq_lock have chances to deadlock anyway and should
> > be switched to printk_deferred().
> > 
> > I think we can queue significantly much less irq_work-s from printk().
> > 
> > Petr, Steven, what do you think?
> 
> Sergey, do you still plan to get this patch merged?
> 
> > 
> > Something like this. Call wake_up_interruptible(), switch to
> > wake_up_klogd() only when called from sched code.
> > 
> > ---
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index cd51aa7d08a9..89cb47882254 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -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.

We want to remove locks from printk() and not add them.

Best Regards,
Petr

  reply	other threads:[~2019-11-18 15:27 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 [this message]
2019-11-19  0:41                                     ` Sergey Senozhatsky
2019-11-19  9:41                                       ` Petr Mladek
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=20191118152738.az364dczadskgimc@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).