Re: [PATCH] mm,page_alloc: softlockup on warn_alloc on
From: Michal Hocko <mhocko@suse.com>
Date: 2017-09-15 14:24:00
On Fri 15-09-17 23:12:24, Tetsuo Handa wrote:
Michal Hocko wrote:quoted
On Fri 15-09-17 21:09:29, Tetsuo Handa wrote:quoted
Michal Hocko wrote:quoted
On Fri 15-09-17 20:38:49, Tetsuo Handa wrote: [...]quoted
You said "identify _why_ we see the lockup trigerring in the first place" without providing means to identify it. Unless you provide means to identify it (in a form which can be immediately and easily backported to 4.9 kernels; that is, backporting not-yet-accepted printk() offloading patchset is not a choice), this patch cannot be refused.I fail to see why. It simply workarounds an existing problem elsewhere in the kernel without deeper understanding on where the problem is. You can add your own instrumentation to debug and describe the problem. This is no different to any other kernel bugs...Please do show us your patch for that. Normal users cannot afford developing such instrumentation to debug and describe the problem.Stop this nonsense already! Any kernel bug/lockup needs a debugging which might be non-trivial and it is necessary to understand the real culprit. We do not add random hacks to silence a problem. We aim at fixing it!Assuming that Wang Yu's trace has RIP: 0010:[<...>] [<...>] dump_stack+0x.../0x... line in the omitted part (like Cong Wang's trace did), I suspect that a thread which is holding dump_lock is unable to leave console_unlock() from printk() for so long because many other threads are trying to call printk() from warn_alloc() while consuming all CPU time.
__dump_stack should be an atomic context AFAIR. But as we already discussed some time ago this lock is not fair and one function might bounce for too long. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>