Messages in this thread | | | Date | Wed, 9 Oct 2013 18:23:36 +0100 | From | Al Viro <> | Subject | Re: 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...
| |