linux-kernel - Re: [3/10 PATCH] inline wake_up

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: <20080625.152334.32728378.davem@davemloft.net>
Date:	Wed, 25 Jun 2008 15:23:34 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	vda.linux@...glemail.com
Cc:	mpatocka@...hat.com, linux-kernel@...r.kernel.org,
	sparclinux@...r.kernel.org
Subject: Re: [3/10 PATCH] inline wake_up_bit

From: Denys Vlasenko <vda.linux@...glemail.com>
Date: Wed, 25 Jun 2008 17:24:57 +0200

> talk to gcc people to remedy insane call convention sounds as a more
> workable solution.

It's not a tenable solution to this problem.  We have to make this
work properly with compiler tools currently available to users, rather
than versions of gcc that don't even exist yet.

And what's more, the amount we can get back from the current stack
size allocation is, at best, 16 bytes.  The problem isn't going away
no matter what we do to the compiler.

> BTW, i386 uses regparm call convention, is similar trick
> possible for sparc64?

sparc64 already passes arguments in registers.

The stack frame is (predominantly, size wise) to accomodate the save
area for the cpu's register windows in non-leaf functions, and that
isn't going anywhere.

Back to the patch set, several of these non-inlined cases really
are extremely suboptimal.  If it's just moving args around, it
should be inline.  This would help even x86.

Also, suggesting that IRQSTACKS are mandatory for correct operation is
a pretty unreasonable thing to say.  It's currently still optional on
the platforms where it is implemented, so I wonder if this means that
correct operation is optional on these platforms? :-)

I have a sparc64 IRQSTACKS implementation that I'm working on, but
it's not something I can stick into 2.6.26 by any stretch of the
imagination.
--
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/