To: Peter Osterlund <petero2@telia.com>
Cc: linux-kernel@vger.kernel.org, dm-devel@redhat.com
Subject: Re: 2.6.24.2: 4KSTACKS + pcdrw + dm + mount -> stack overflow: ide-cd related? dm-related?
References: <87wsovkth5.fsf@hades.wkstn.nix> <87skzipcpw.fsf@hades.wkstn.nix>
	<m363wepa3a.fsf@telia.com>
From: Nix <nix@esperi.org.uk>
Emacs: if it payed rent for disk space, you'd be rich.
Date: Sun, 24 Feb 2008 17:02:26 +0000
In-Reply-To: <m363wepa3a.fsf@telia.com> (Peter Osterlund's message of "Sun, 24 Feb 2008 17:56:09 +0100")
Message-ID: <87oda6p9st.fsf@hades.wkstn.nix>
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.5-b28 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1401
Lines: 39

On 24 Feb 2008, Peter Osterlund told this:

> Nix <nix@esperi.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...)


I'll try the patch after this series of backups is done :)

-- 
`The rest is a tale of post and counter-post.' --- Ian Rawlings
                                                   describes USENET
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/