[Top] [All Lists]

Re: 3.14-rc2 XFS backtrace because irqs_disabled.

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: 3.14-rc2 XFS backtrace because irqs_disabled.
From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 11 Feb 2014 22:28:12 -0800
Cc: Al Viro <viro@xxxxxxxxxxxxxxxxxx>, Dave Jones <davej@xxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxxx>, Linux Kernel <linux-kernel@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=78nKlVTEs3oU8QVczVJ4mMiPOxwrPe9ZM8RxrTrfkaw=; b=XpANSGXFH7x9ucpR6Q9HlKph3AdWL+Nu8M/tnYtF7RsNI9mIP9hTzRUfyRhIx6+xQX UfgXRP5yPCpSgN1K+KXwOAW/2H2GSb33V8wnebsNjVPJ6Bg+iTlWdZBsy621VpJRXYpE 7rvEsyJqf/r+UKEU+LqKE4Yz9FTLniozQjB02Ul6BdmxnEwfbCHnvLONzvxWNkV1h7Ec Zb2qQRbSnVzllRJAheOy7aN9RoWhWAmSw3l8RnTUV0Xca95CNjYARheyd1E+OqlPky8S Rtpi+iUhLuPFra41Eu/jk2Jt9OX6kz+MprfWYaj1kbtLFKdY2qcbpf9XJWdQvNQ6I4Sg xmUQ==
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=78nKlVTEs3oU8QVczVJ4mMiPOxwrPe9ZM8RxrTrfkaw=; b=ebnZqBsBqX93PBMDYNDb0qztthi3JZOkHaTPvjGWtCyS409KASNlOrNY3yBkORABrx SEBq76k/vRI1wQ5yxd/C/oVIAQSKhPAPk9qJ8zBpNuXh3ROM7weltd42X9XKfk04beeL 4PllUz2wRAwGw72aTzFJUco0Wm6mGOi3T80Fw=
In-reply-to: <20140212054043.GB13997@dastard>
References: <20140211172707.GA1749@xxxxxxxxxx> <20140211210841.GM13647@dastard> <52FA9ADA.9040803@xxxxxxxxxxx> <20140212004403.GA17129@xxxxxxxxxx> <20140212010941.GM18016@xxxxxxxxxxxxxxxxxx> <CA+55aFwoWT-0A_KTkXMkNqOy8hc=YmouTMBgWUD_z+8qYPphjA@xxxxxxxxxxxxxx> <20140212040358.GA25327@xxxxxxxxxx> <20140212042215.GN18016@xxxxxxxxxxxxxxxxxx> <20140212054043.GB13997@dastard>
Sender: linus971@xxxxxxxxx
On Tue, Feb 11, 2014 at 9:40 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> None of the XFS code disables interrupts in that path, not does is
> call outside XFS except to dispatch IO. The stack is pretty deep at
> this point and I know that the standard (non stacked) IO stack can
> consume >3kb of stack space when it gets down to having to do memory
> reclaim during GFP_NOIO allocation at the lowest level of SCSI
> drivers. Stack overruns typically show up with symptoms like we are
> seeing.

That would also explain why it shows up for do_coredump(), even though
clearly interrupts are not disabled at that point. It's just because
do_coredump() opens a filename at a deeper point in the stack than the
more normal system call paths do.

It looks like just "do_signal()" has a stack frame that is about 230
bytes even under normal circumstancs (largely due to "struct ksignal"
- which in turn is largely due to the insane 128-byte padding in
siginfo_t). Add a few other frames in there, and I guess that if it
was close before, the coredump path just makes it go off.

And some of the debug options that I'm sure DaveJ has enabled tend to
make the stack usage worse (simply because they make a lot of data
structures bigger).


<Prev in Thread] Current Thread [Next in Thread>