linux-kernel - Re: [PATCH] sparc, exec: remove redundant addr

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:	Sat, 11 Jun 2011 17:58:34 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	viro@...IV.linux.org.uk
Cc:	minipli@...glemail.com, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, sparclinux@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sparc, exec: remove redundant addr_limit assignment

From: Al Viro <viro@...IV.linux.org.uk>
Date: Sun, 12 Jun 2011 00:44:15 +0100

> On Sat, Jun 11, 2011 at 04:08:42PM -0700, David Miller wrote:
>> From: Mathias Krause <minipli@...glemail.com>
>> Date: Fri, 10 Jun 2011 15:10:53 +0200
>> 
>> > @@ -368,9 +368,6 @@ void flush_thread(void)
>> >  
>> >  	/* Clear FPU register state. */
>> >  	t->fpsaved[0] = 0;
>> > -	
>> > -	if (get_thread_current_ds() != ASI_AIUS)
>> > -		set_fs(USER_DS);
>> >  }
>> 
>> Yeah but now you're doing it unconditionally, the guard is here
>> because the %asi register write which set_fs() does is extremely
>> expensive on sparc64 and %99.99999 of the time we can avoid it.
> 
> OTOH, get_thread_current_ds() is cheap and moving that into set_fs()
> itself wouldn't be particulary bad idea...

The reason the test is only in this specific spot, is that's the only
place where the optimization makes any sense.

The rest of the time it's in compat layer code or similar, where we
know the set_fs() is actually necessary.

Therefore, expanding the test into every set_fs() call would be
wasteful.
--
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/