From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Qian Cai <cai@lca.pw>, Steven Rostedt <rostedt@goodmis.org>,
Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@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: Thu, 5 Sep 2019 20:32:08 +0900 [thread overview]
Message-ID: <20190905113208.GA521@jagdpanzerIV> (raw)
In-Reply-To: <1567629737.5576.87.camel@lca.pw>
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?
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);
+ } else {
wake_up_klogd();
+ }
return printed_len;
}
EXPORT_SYMBOL(vprintk_emit);
---
> and could deal with console hardware that involve irq_exit() anyway.
printk->console_driver->write() does not involve irq.
> On the other hand, adding __GPF_NOWARN in the build_skb() allocation will fix
> this known NET_TX_SOFTIRQ case which is common when softirqd involved at least
> in short-term. It even have a benefit to reduce the overall warn_alloc() noise
> out there.
That's not up to me to decide.
-ss
next prev parent reply other threads:[~2019-09-05 11:32 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 [this message]
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
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-04 6:15 ` Michal Hocko
2019-09-02 14:24 ` Vlastimil Babka
2019-09-03 10:23 ` Qian Cai
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=20190905113208.GA521@jagdpanzerIV \
--to=sergey.senozhatsky.work@gmail.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=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--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).