linux-kernel - Re: 2.6.21-rc5-mm[12]: Oops on bootup in xor_see

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: <17934.54983.192724.145829@notabene.brown>
Date:	Sun, 1 Apr 2007 07:46:47 +1000
From:	Neil Brown <neilb@...e.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Bernhard Rosenkraenzer <bero@...linux.org>,
	linux-kernel@...r.kernel.org,
	Dan Williams <dan.j.williams@...el.com>
Subject: Re: 2.6.21-rc5-mm[12]: Oops on bootup in xor_see_2

On Saturday March 31, akpm@...ux-foundation.org wrote:
> On Sat, 31 Mar 2007 17:36:47 +0000 Bernhard Rosenkraenzer <bero@...linux.org> wrote:
> 
> > I'm getting this Oops when booting an 2.6.21-rc5-mm1 or 2.6.21-rc5-mm2 on an 
> > Acer Aspire 1501 LMi in 32 bit mode (2.6.21-rc4-mm1 + hotfixes works 
> > perfectly):
> > 
> > xor: automatically using best checksumming function: pIII_sse

Hmmm... I've seen that before

> > Code: 44 89 74 24 48 0f 20 c6 0f 06 0f 11 04 24 0f 11 4c 24 10 0f 11 54 24 20 
> > 0f
> >       11 5c 24 30 0f 18 82 00 01 00 00 0f 18 82 20 01 00 00 <00> 00 00 00 00 
> > 00
> >       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > -

Them bytes that look like '00' are mostly supposed to look like 'F0' -
an x86 'noop'.

Apparently a bin-utils bug.  An alpha of OpenSUSE-10.3 was compiling
kernels like this.  I'm told it has been fixed.

What distro/gcc version/binutils version was this compiled on?

It is possible that we should change the ".align 32" in
include/asm-i386/xor.h to ".align 32, 0xf0" or similar, but my
assembler knowledge stopped growing when it reached 6809, so I'd
rather someone who knew something about it did anything that was
required....

> 
> Dan, I'm assuming your changes in there are the cause of this.  AFAICT all
> you're doing is moving code around, so it's a bit odd.
> 
> Bernhard, the config would be useful please.
> 
> Neil, is calibrate_xor_block() being rational?
> 
> 	b1 = (void *) __get_free_pages(GFP_KERNEL, 2);
> 	...
> 	b2 = b1 + 2*PAGE_SIZE + BENCH_SIZE;
> 
> Is it correct to add BENCH_SIZE to b2 here?

I think it is intentional.  I cannot say if it is correct.
The purpose is to defeat cache effects somehow.
The result of that code together with the value of BENCH_SIZE being
PAGE_SIZE is that 4 pages are allocated, and the first and last are
used.
I have no idea how any cache would treat this, but that seems to be
the intent of the code.

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