xfs
[Top] [All Lists]

Re: 3.14-rc2 XFS backtrace because irqs_disabled.

To: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
Subject: Re: 3.14-rc2 XFS backtrace because irqs_disabled.
From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 12 Feb 2014 12:13:19 -0800
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, 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=xfDgFQJobIJyxmGf0r7sekaEYJorCdqYs4kFM9Zhno4=; b=vV4C0Xq5HthA+Gm0vYxLyaN0NVEnhN6bIbWktQarXJIY6H2k4WrSAC6YbOC6Xk66S1 RLUL1DvUZSsrA/R2tZf4NBKiTwl9Ae0dnF/6vRIGkNB1Us35gbSLHRNHChpuYUrgMuXF SdmU8jF4dqjJyNgkkEmRQsykaGBYK5p7ReCGAoo9q+X4lyeW6J38qCnXNuhO+3HOMFiF IIogeg8q3w5+yi2/0yDOLW84P/IyQSdeuRpDOQ+f7lhuKYYiDwBy6Aiuju2lT/XbT2Wa yE+Z9Vyr/B9Pz+MVJlYjsfl0vQe/SYg4SQt8UY0nKfQocK0si+gu1zUCGqk6SCy/bd9F uf5g==
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=xfDgFQJobIJyxmGf0r7sekaEYJorCdqYs4kFM9Zhno4=; b=PBkwEcNJbJ/2paTYadOLN08ZvF7L8iWgJxyGsOL5cM9j0U+3omTI/hmEFHf1qy5HN2 18tSRrfveMv7x9N3rUvHqSF+TTJ8AQcA5cgkl8MHBm9NGvs+MVjDFWuAJjc8rfG6sSIf XNmFw5zxUIVWmsiJQJJ2JlHiwJkh863h7I0Wc=
In-reply-to: <20140212113928.GO18016@xxxxxxxxxxxxxxxxxx>
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> <CA+55aFxy2t7bnCUc-DhhxYxsZ0+GwL9GuQXRYtE_VzqZusmB9A@xxxxxxxxxxxxxx> <20140212113928.GO18016@xxxxxxxxxxxxxxxxxx>
Sender: linus971@xxxxxxxxx
On Wed, Feb 12, 2014 at 3:39 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Feb 11, 2014 at 10:28:12PM -0800, Linus Torvalds wrote:
>
>> 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.
>
> We could, in principle, put it into task_struct and make get_signal()
> return its address - do_signal() is called only in the code that does
> assorted returns to userland...

We have better uses for random buffers in "struct task_struct", I'd
hate to put a siginfo_t there.

The thing is, siginfo_t has that idiotic 128-byte area, but it's all
"for future expansion". I think it's some damn glibc disease - we've
seen these kinds of insane paddings before.

The actual *useful* part of siginfo_t is on the order of 32 bytes. If that.

Sad.

                Linus

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