linux-kernel - Re: [PATCH] x86: make use of inc/dec conditional

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:	Wed, 19 Aug 2009 09:48:30 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jan Beulich <JBeulich@...ell.com>
CC:	mingo@...e.hu, tglx@...utronix.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: make use of inc/dec conditional

On 08/19/2009 12:48 AM, Jan Beulich wrote:
> According to gcc's instruction selection, inc/dec can be used without
> penalty on most CPU models, but should be avoided on others. Hence we
> should have a config option controlling the use of inc/dec, and
> respective abstraction macros to avoid making the resulting code too
> ugly. There are a few instances of inc/dec that must be retained in
> assembly code, due to that code's dependency on the instruction not
> changing the carry flag.

One thing: I doubt it matters one measurable iota when it comes to
locked operations.

Furthermore:

-		     "decl %2	;\n"
+		     _ASM_DECL "%2	;\n"
 		     "jne 1b		;\n"
 		     "adcl $0, %0	;\n"

It looks to me that the carry flag is live across the dec there.  The
other csum code look scary to me too.

The rest of them look technically okay, but you're bloating them by two
bytes (one byte in 64-bit mode) for every instance.  You may want to
consider if any particular instance is more icache-critical than
stall-critical.  This is probably more of a concern for inlines than for
regular single-instance code like the string operations.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
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/