Re: 2.6.37-rc7: Regression: b43: crashes in hwrng_register()

From: Mario 'BitKoenig' Holbe
Date: Tue Jan 04 2011 - 22:52:42 EST


On Wed, Jan 05, 2011 at 11:30:20AM +1100, Herbert Xu wrote:
> OK, so xstore really is producing crap. Can you try this path
> (also against vanilla) to print out some extra info?

All right, here is what happens...

On top of your 3rd patch:

--- linux-source-2.6.37-rc7/drivers/char/hw_random/via-rng.c.hxu3 2011-01-05 04:13:09.452322117 +0100
+++ linux-source-2.6.37-rc7/drivers/char/hw_random/via-rng.c 2011-01-05 03:59:33.169316276 +0100
@@ -97,6 +97,10 @@ static int via_rng_data_present(struct h
u32 bytes_out;
int i;

+ printk(KERN_DEBUG "buf=%p + %zu, via_rng_datum=%p\n",
+ buf, sizeof(buf), via_rng_datum);
+
+
/* We choose the recommended 1-byte-per-instruction RNG rate,
* for greater randomness at the expense of speed. Larger
* values 2, 4, or 8 bytes-per-instruction yield greater

gives:

[ 103.276337] buf=f6e23f28 + 28, via_rng_datum=f6e23f30
[ 103.276351] f6e23f38 0x0 0x8
[ 103.276371] buf=f6e23f28 + 28, via_rng_datum=f6e23f30
[ 103.276380] f6e23f38 0xffffffff 0x8
...

According to the VIA PadLock Programming Guide, XSTORE increments EDI by
the number of bytes stored.
This did obviously not matter as long as the buffer was "sufficiently
distant", but now you have the buffer close on the stack and I believe,
the optimizer crops up, hence the EDI increment begins to matter.

IMHO EDI (and EDX - for completeness :)) should be put on the asm
clobber-list, but if I try to do it, I always get:
error: can't find a register in class 'DIREG' while reloading 'asm'
error: 'asm' operand has impossible constraints

So... I have the reason - solution is up to you :)

Btw: the 8 bytes increment (as well as the 8 in EAX 4:0) proves that
XSTOR indeed writes more than 32bit :)


g'nite
Mario
--
The only thing to be scared of, son, is tomorrow.
I don't live for tomorrow. Never saw the fun in it.
-- Denny Crane, Boston Legal

Attachment: signature.asc
Description: Digital signature