lkml.org 
[lkml]   [2013]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 3.11.4: kernel BUG at fs/buffer.c:1268
On Wed, Oct 09, 2013 at 05:18:53PM +0200, Jan Kara wrote:

> This is really weird. We are delivering a signal to a task. While task is

ITYM "a fatal signal"

> returning from kernel space we are running queued task works and one of

get_signal_to_deliver() notices that the signal has to be dealt with
via default reaction, which happens to be "die, you bastard". So it
calls do_group_exit(). Which means that we'll never be returning to userland,
so the time to run pending __fput() is now.

> that works is dropping last file reference. Ext4 then does some data
> flushing and at that point we find out irqs are disabled. It isn't really
> clear to me where in that call chain got irqs disabled. I went through it
> and didn't find any such place... If this is reproducible, there would be
> ways to debug this (like irq tracing). Otherwise I'm not sure... I'm CCing
> Al since he was digging in this code recently. Maybe he will have some
> idea.

Note that do_group_exit() is preceded by
spin_unlock_irq(&sighand->siglock);
so no matter what happened in callers, irq is enabled. I'd suggest sticking
such BUG_ON() into __fput() and trying to reproduce that crap...


\
 
 \ /
  Last update: 2013-10-09 19:41    [W:0.097 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site