Re: [PATCH] mm,page_alloc: softlockup on warn_alloc on

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri 15-09-17 23:12:24, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Fri 15-09-17 21:09:29, Tetsuo Handa wrote:
> > > Michal Hocko wrote:
> > > > On Fri 15-09-17 20:38:49, Tetsuo Handa wrote:
> > > > [...]
> > > > > 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@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux