| To: | Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: 3.14-rc2 XFS backtrace because irqs_disabled. |
| From: | Tejun Heo <tj@xxxxxxxxxx> |
| Date: | Wed, 12 Feb 2014 03:13:33 -0500 |
| Cc: | Dave Chinner <david@xxxxxxxxxxxxx>, Jens Axboe <axboe@xxxxxxxxx>, Steven Rostedt <rostedt@xxxxxxxxxxx>, Dave Jones <davej@xxxxxxxxxx>, Al Viro <viro@xxxxxxxxxxxxxxxxxx>, 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=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=h6JiQsdmAsH1c2ZWvC3Cv5OrudyLBPk/C7kyWMnsjZg=; b=OYMnLco96fpF+5Qit2Uzijg52Rf6B1Ap/mnd/H/kXfVBlvOEoegD7R/enuwsGcE8Yi cHEXwiumRjDNTBkzgy+hbbsQXk8tD0s3lOPEEY0F2e1q+fx1mD6GfqX9MuPb83Xldya2 SdGZrVT3zCFez3FOruNs1oGoSuOq5bJ9rZY+Vr87M4s0C51bJpJIaYPEzxzNzodgGNWR qbQF65jLkCJbyyb2nE3MsYRRritF1k9osPzejGrAbxrndExqj515j4r6h2SXQTC4OiOo ZL1LwatTrLbJHKFzdCNtuBcnf5LHLmTmwpbeopBOf4Sni4KzpBX0kB9kp0dpSXhAqBzh S1TA== |
| In-reply-to: | <CA+55aFyp91=1seVT0ZV8T+GjOuafWvvjHNHn+MKGydsG+8eUEQ@xxxxxxxxxxxxxx> |
| References: | <20140212004403.GA17129@xxxxxxxxxx> <20140212010941.GM18016@xxxxxxxxxxxxxxxxxx> <CA+55aFwoWT-0A_KTkXMkNqOy8hc=YmouTMBgWUD_z+8qYPphjA@xxxxxxxxxxxxxx> <20140212040358.GA25327@xxxxxxxxxx> <20140212042215.GN18016@xxxxxxxxxxxxxxxxxx> <20140212054043.GB13997@dastard> <20140212055027.GA28502@xxxxxxxxxx> <20140212061038.GC13997@dastard> <20140212063150.GD13997@dastard> <CA+55aFyp91=1seVT0ZV8T+GjOuafWvvjHNHn+MKGydsG+8eUEQ@xxxxxxxxxxxxxx> |
| Sender: | Tejun Heo <htejun@xxxxxxxxx> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
On Tue, Feb 11, 2014 at 10:59:58PM -0800, Linus Torvalds wrote: > There's a lot of 200+ byte stack frames in block/blk-core.s, and they > all seem to be of the type perf_trace_block_buffer() - things created > with DECLARE_EVENT_CLASS(), afaik. Why they all have 200+ bytes of > frame, I have no idea. That sounds like a potential disaster too, > although hopefully it's mostly leaf functions - but leaf functions > *deep* in the callchain. Tejun? Steven, why _do_ they end up with such > huge frames? It looks like they're essentially the same for all the automatically generated trace functions. I'm seeing 232 byte stack frame in most of them. If I'm not completely confused by these macros, these are generated by DECLARE_EVENT_CLASS() in include/trace/ftrace.h and contains struct pt_regs in the stack frame which is already 168 bytes, so that seems like the culprit. No idea whether this is something avoidable. At least they shouldn't nest in any way. Steven? Thanks. -- tejun |
| Previous by Date: | 3.14-rc2: RECLAIM_FS-safe -> RECLAIM_FS-unsafe lock order detected, Christian Kujau |
|---|---|
| Next by Date: | Re: 3.14-rc2: RECLAIM_FS-safe -> RECLAIM_FS-unsafe lock order detected, Christian Kujau |
| Previous by Thread: | Re: 3.14-rc2 XFS backtrace because irqs_disabled., Linus Torvalds |
| Next by Thread: | Re: 3.14-rc2 XFS backtrace because irqs_disabled., Steven Rostedt |
| Indexes: | [Date] [Thread] [Top] [All Lists] |