linux-kernel - Re: LOCK prefix on uni processor has its use

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] [day] [month] [year] [list]

Message-Id: <200906030646.19493.lkml@morethan.org>
Date:	Wed, 3 Jun 2009 06:46:17 -0500
From:	"Michael S. Zick" <lkml@...ethan.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Harald Welte <HaraldWelte@...tech.com>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: LOCK prefix on uni processor has its use

On Tue June 2 2009, Andi Kleen wrote:
> > After another week of chasing this - -
> 
> Did you use the "compile part of the kernel with LOCK and others without"
> technique I described earlier?
> 

That would only help if it where a single point failure.

Although there are some assembly language things that can
be done to help in finding what to examine, like:

#define LOCK_PREFIX     "\n### Lock pre-fix removed:\n\t"

Or whatever might help your favorite text search program.

Which yields asm expansion in your *.s file (gcc -S) as:

#APP
# 33 "test_bytelock.c" 1

1:      xchgb %ah, %al
        test %al,%al
        jz 3f

### Lock pre-fix removed:
        incb splock+1
2:      xchgw %ax, %ax
        cmpb $1, splock
        je 2b

### Lock pre-fix removed:
        decb splock+1
        jmp 1b
3:
# 0 "" 2
#NO_APP

Note: For the readers not familar with (g)as;
#APP -> Assembler Pre-Process (gcc generated)
<ragged whitespace and comments allowed>
#NO_APP -> No Assembler Pre-Process (gcc generated)

If ambitious, you can add a comment to each asm-macro
to note the line and source filename of where it is
defined. (the line number and name gcc put there is
where it was expanded, not where it was defined).

Not really too ambitious - there are only 140 files
of interest (with asm-macros) in a x86, uni-processor build.

Mike

> -Andi


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