linux-kernel - Re: [tip:tracing/urgent] tracing: Fix too large stack usage in do_one

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.01.0908211207410.3158@localhost.localdomain>
Date:	Fri, 21 Aug 2009 12:13:03 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-tip-commits@...r.kernel.org,
	Arjan van de Ven <arjan@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Dave Jones <davej@...hat.com>,
	Kyle McMartin <kyle@...artin.ca>, Greg KH <gregkh@...e.de>,
	linux-kernel@...r.kernel.org, hpa@...or.com, mingo@...hat.com,
	catalin.marinas@....com, a.p.zijlstra@...llo.nl,
	jens.axboe@...cle.com, fweisbec@...il.com, stable@...nel.org,
	srostedt@...hat.com, tglx@...utronix.de
Subject: Re: [tip:tracing/urgent] tracing: Fix too large stack usage in
 do_one_initcall()



On Fri, 21 Aug 2009, Ingo Molnar wrote:
> > 
> > That's why I think the async thing could fix this - if we _force_ 
> > async calls to be asynchronous, you won't have the deep callchains 
> > for all the device discovery thing.
> 
> Agreed. OTOH we have deep callchains in things like execve() too 
> which seem to be a lot harder to fix - and those have been around 
> for the past ~10 years since i've been looking at max-stacktraces.
> I think 4K doesnt cut it anymore.

I agree that we have stack traces that are too deep in other areas too. At 
the same time, it does tend to be the case that initcalls are special due 
to having those long chains of detection (PCI -> driver -> bus -> device), 
so targeting them specially is probably a good idea. 

(There are other "special" chains that tend to be long, like "mount": 
you often end up doing things like reading root inode information etc down 
a fairly deep chain).

And we probably should really complain more actively about big stack 
frames. We have that CONFIG_FRAME_WARN thing, but it's set very high. 

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/