linux-kernel - Re: [PATCH] Fix print out of function which called WARN

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]

Date:	Sun, 17 May 2009 15:47:21 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Miller <davem@...emloft.net>
cc:	hugh@...itas.com, ak@...ux.intel.com, ian.campbell@...rix.com,
	jakub@...hat.com, linux-kernel@...r.kernel.org,
	jesper.nilsson@...s.com, hannes@...xchg.org, arjan@...ux.intel.com,
	akpm@...ux-foundation.org
Subject: Re: [PATCH] Fix print out of function which called WARN_ON()

On Sun, 17 May 2009, David Miller wrote:
> 
> There is some strageness wrt. varargs in that it seems that the opaque
> object used to reference varargs is effectively an array which
> includes first the arguments passed in registers and then the
> non-register stack args.

I forget what the exact details were, but I _think_ it boiled down to the 
varargs save area is always large enough for the maximum number of 
register arguments. Fair enough. It used to be that that means something 
like 216 bytes of stack-space with SSE registers (8*16 bytes for just 
that unused SSE register save).

So I reported that, and my fix got merged (or rather, I think somebody 
improved on my hacky one and that improved fix got merged).

But now it still generates a 88 byte stack frame, and only about half that 
seems to be used (six integer registers, but the "..." part can only be 
five, so you have 5*8=40 bytes save-space, and an additional pointer to 
the frame that contains the rest).

So the stack frame _should_ be just 48 bytes, but gcc always seems to 
generate either 80 or 88 bytes. I never bothered to try to chase it down, 
the code is rather obscure. I suspect it has some "current pointer" too 
etc, and there is probably some alignment as well. But I'm sure that there 
are entries on the stack frame that simply aren't filled in.

At least with the XMM fix, there's now just a _couple_ of such entries. 

> I never got down to the details yet, but on sparc64 currently we
> always eat that extra space

Ouch. On x86-64, it at least _only_ happens in the functions that do 
va_start().

				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/