linux-kernel - Re: 2.6.24.2: 4KSTACKS + pcdrw + dm + mount -> stack overflow: ide-cd related? dm-related?

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20080225123041.401da103.akpm@linux-foundation.org>
Date:	Mon, 25 Feb 2008 12:30:41 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Nix <nix@...eri.org.uk>
Cc:	Peter Osterlund <petero2@...ia.com>, linux-kernel@...r.kernel.org,
	dm-devel@...hat.com, Jan Kara <jack@....cz>
Subject: Re: 2.6.24.2: 4KSTACKS + pcdrw + dm + mount -> stack overflow:
 ide-cd related? dm-related?

On Sun, 24 Feb 2008 17:02:26 +0000 Nix <nix@...eri.org.uk> wrote:

> On 24 Feb 2008, Peter Osterlund told this:
> 
> > Nix <nix@...eri.org.uk> writes:
> >> But while I'd normally blame pktcdvd there's only one pktcdvd function
> >> in these tracebacks (pkt_open) and it's not got a significant stack
> >> footprint.
> >
> > Did you verify that with "make checkstack" or just by looking at the
> > source code? On my system, pkt_open() consumes 584 bytes because the
> > compiler decides to inline lots of functions that would not normally
> > be part of long call chains. The following patch fixes that problem on
> > my system.
> 
> I just looked at the source; I forgot `make checkstack' existed.
> 
> On this system:
> 
> 0xc0263e0f pkt_open [vmlinux]:                          556
> 
> which is nearly as bad.
> 
> (As an aside, I'm surprised I didn't oops when packet-writing as well:
> 
> 0xc021270d udf_process_sequence [vmlinux]:              692
> 0xc020f43d udf_add_entry [vmlinux]:                     628
> 
> owch. I guess that's called via a shorter call chain...)

udf_process_sequence() seems to be another victim of gcc inlining.

udf_add_entry() defines a couple of 256-byte local arrays.
--
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/