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

Previous thread: IOMMU and DMA mode of pata_jmicron by Steffen Moser on Tuesday, December 28, 2010 - 4:43 pm. (5 messages)

Next thread: [PATCH] usb: pch_udc: Fixed issue which does not work with g_serial by Toshiharu Okada on Tuesday, December 28, 2010 - 6:07 pm. (1 message)
From: Larry Finger
Date: Tuesday, December 28, 2010 - 5:34 pm

power_meter pci_slot hed fan container acpi_cpufreq mperf cpufreq_conservative
cpufreq_userspace cpufreq_stats cpufreq_powersave dm_crypt fuse loop eeprom
via_cputemp i2c_dev nvram padlock_aes aes_i586 aes_generic padlock_sha
sha256_generic sha1_generic via_rng msr cpuid snd_hda_codec_realtek
snd_hda_intel snd_hda_codec arc4 snd_hwdep ecb snd_pcm_oss snd_mixer_oss snd_pcm
snd_seq_midi b43 snd_rawmidi uvcvideo snd_seq_midi_event joydev videodev btusb
snd_seq rng_core video ac battery tpm_tis v4l1_compat tpm tpm_bios output
power_supply i2c_viapro snd_timer ideapad_laptop snd_seq_device serio_raw wmi
mac80211 cfg80211 processor snd pcspkr i2c_core psmouse button bluetooth evdev
shpchp soundcore snd_page_alloc rfkill pci_hotplug ext3 jbd mbcache raid10
raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
raid1 raid0 multipath linear md_mod dm_mirror dm_region_hash dm_log dm_mod btrfs zli
b_deflate crc32c libcrc32c sd_mod crc_t10dif ata_generic uhci_hcd pata_via
libata ssb ehci_hcd tg3 scsi_mod usbcore pcmcia via_sdmmc mmc_core pcmcia_core
11 3f c8 85 c0 75 0a be ef ff ff ff e9 d3 00 00 00 8b 76 1c 83 ee 1c <8b> 46 1c

I almost missed this posting. Please post wireless problems with
linux-wireless@vger.kernel.org for better visibility.

I have a BCM4312 (14e4:4315) on a netbook that does not have this problem, thus
I will have to rely on your debugging. An additional difficulty is that the only
changes to b43 between 2.6.36 and 2.6.37 are adding an additional PCI ID, some
fixes to the SDIO driver, and some code for an 802.11n device. None of these
should affect your 802.11 b/g unit.

Is it possible for you to bisect between 2.6.36 and 2.6.37-rc5? I wish I could
suggest some way to minimize the number of commits and builds, but the problem
could be anywhere.

Larry
--

From: Mario 'BitKoenig' Holbe
Date: Wednesday, December 29, 2010 - 12:54 pm

Hello Larry,




To be honest, I never bisected such a huge amount of commits before and
I'm somewhat afraid of doing it.

However, I think I'm able to nail the issue down to:
commit 84c164a34ffe67908a932a2d641ec1a80c2d5435 which went to 2.6.37-rc1.
Author: John W. Linville <linville@tuxdriver.com>
Date:   Fri Aug 6 15:31:45 2010 -0400

    b43: move hwrng registration driver to wireless core initialization

Message-ID: <1281126412-5089-1-git-send-email-linville@tuxdriver.com>
http://marc.info/?l=linux-wireless&m=128112658829379&w=2

I did 2 things:
1. I (manually) reverted 84c164a34ffe67908a932a2d641ec1a80c2d5435 from
   2.6.37-rc7: The crash disappears, b43 is useable.
2. I added 84c164a34ffe67908a932a2d641ec1a80c2d5435 to 2.6.36.2: The
   crash shows up as with vanilla 2.6.37-rc7.

I'm not sure why this is not reproducible for you, probably it has
something to do with the VIA Nano having a second HW-RNG driven by
via-rng. I experienced crashes in the past with earlier kernels when I
tried to move RNGs around via /sys/devices/virtual/misc/hw_random, but
never took the time to trace them down since I just got it working :)

Oh, I'm still able to trigger a crash with
$ cat /sys/devices/virtual/misc/hw_random/rng_available
on 2.6.37-rc7 without 84c164a34ffe67908a932a2d641ec1a80c2d5435 as well
as on vanilla 2.6.36.2. Probably this is (better) reproducible for you?

I suspect both (the 84c164a34ffe67908a932a2d641ec1a80c2d5435 crash as
well as the cat rng_available crash) having something to do with a
partially uninitialized rng-struct, or better: parts of the rng-struct
that are free()d too early (i.e. within its lifetime).


regards
   Mario
-- 
Doing it right is no excuse for not meeting the schedule.
                                -- Plant Manager, Delphi Corporation
From: Larry Finger
Date: Wednesday, December 29, 2010 - 5:30 pm

Thanks for finding the problem. Obviously, I did not go back far enough in the
record to find the commit that you implicate.

Please show the output of "egrep "B43|RNG|RANDOM" .config".

It should not matter, but please try the attached patch.

Larry
From: Mario 'BitKoenig' Holbe
Date: Wednesday, December 29, 2010 - 6:20 pm

CONFIG_B43=m
CONFIG_B43_PCI_AUTOSELECT=y
CONFIG_B43_PCICORE_AUTOSELECT=y
CONFIG_B43_PCMCIA=y
CONFIG_B43_SDIO=y
CONFIG_B43_PIO=y
CONFIG_B43_PHY_LP=y
CONFIG_B43_LEDS=y
CONFIG_B43_HWRNG=y
# CONFIG_B43_DEBUG is not set
CONFIG_B43LEGACY=m
CONFIG_B43LEGACY_PCI_AUTOSELECT=y
CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y
CONFIG_B43LEGACY_LEDS=y
CONFIG_B43LEGACY_HWRNG=y
CONFIG_B43LEGACY_DEBUG=y
CONFIG_B43LEGACY_DMA=y
CONFIG_B43LEGACY_PIO=y
CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y
# CONFIG_B43LEGACY_DMA_MODE is not set
# CONFIG_B43LEGACY_PIO_MODE is not set
CONFIG_HW_RANDOM=m
CONFIG_HW_RANDOM_TIMERIOMEM=m
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_GEODE=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_SSB_B43_PCI_BRIDGE=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_ANSI_CPRNG=m

It will surely not matter: if CONFIG_B43_HWRNG would not have been
defined, hwrng_register() would not have been reached in the dump from
my first mail.

If you really like me to try that patch, I'll do so when I'm awake again
and will then answer you that nothing has changed :)


Mario
-- 
It is a capital mistake to theorize before one has data.
Insensibly one begins to twist facts to suit theories instead of theories
to suit facts.                   -- Sherlock Holmes by Arthur Conan Doyle
From: Larry Finger
Date: Wednesday, December 29, 2010 - 7:37 pm

No, don't bother. I do have a different request. The byte counts for my 32-bit
system do not match yours. Could you please use the following command to find
the instructions that are failing?

objdump -l -d drivers/char/hw_random/core.o | less

Use the search to find the start of hwrng_register, then add 0x4c to the
starting address. Once I see hte instruction that is failing, I should be able
to find where the failure occurs.

The order in which things are registered should not cause an error, but who knows?

Larry
--

From: Mario 'BitKoenig' Holbe
Date: Thursday, December 30, 2010 - 7:34 am

Alright, here we go...

[   30.012695] BUG: unable to handle kernel paging request at 4b28f458
[   30.012708] IP: [<f90703cc>] hwrng_register+0x4c/0x139 [rng_core]

00000380 <hwrng_register>:
hwrng_register():
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:299
 380:   56                      push   %esi
 381:   53                      push   %ebx
...
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:312
 3c6:   8b 76 1c                mov    0x1c(%esi),%esi
 3c9:   83 ee 1c                sub    $0x1c,%esi
prefetch():
/tmp/1/linux-source-2.6.37-rc7/arch/x86/include/asm/processor.h:837
 3cc:   8b 46 1c                mov    0x1c(%esi),%eax
 3cf:   8d 74 26 00             lea    0x0(%esi,%eiz,1),%esi
hwrng_register():
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:312
 3d3:   81 fe f8 ff ff ff       cmp    $0xfffffff8,%esi
 3d9:   75 d4                   jne    3af <hwrng_register+0x2f>
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:319

   312		list_for_each_entry(tmp, &rng_list, list) {
   313			if (strcmp(tmp->name, rng->name) == 0)
   314				goto out_unlock;
   315		}

This is btw. the same data that is accessed in the cat rng_available
crash via hwrng_attr_available_show():

[  389.303538] BUG: unable to handle kernel paging request at 288dcb5b                              
[  389.303553] IP: [<f8dda34c>] hwrng_attr_available_show+0x5c/0x90 [rng_core]                      

000002f0 <hwrng_attr_available_show>:
hwrng_attr_available_show():
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:236
 2f0:   55                      push   %ebp
...
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:245
 346:   8b 5b 1c                mov    0x1c(%ebx),%ebx
 349:   83 eb 1c                sub    $0x1c,%ebx
prefetch():
/tmp/1/linux-source-2.6.37-rc7/arch/x86/include/asm/processor.h:837
 34c:   8b 43 1c                mov    0x1c(%ebx),%eax
 34f:   8d 74 26 00             lea    ...
From: Larry Finger
Date: Thursday, December 30, 2010 - 11:37 am

The head of the rng_list is damaged. It is initialized at compile time and
should be OK. To help discover the order in which hwrng_register() is called,
apply the attached patch. Run it once with commit 84c164a34ffe67908a installed,
and once with it reverted.

Thanks,

Larry



From: Mario 'BitKoenig' Holbe
Date: Thursday, December 30, 2010 - 1:45 pm

All right, 3 dmesg excerpts attached...
2.6.37-rc7-vanilla.dmesg:
	2.6.37-rc7 vanilla (i.e. with 84c164a34ffe67908a), crashing
	via-rng is registered first, b43-rng second
2.6.37-rc7-without.dmesg:
	2.6.37-rc7 with 84c164a34ffe67908a reverted, not crashing
	b43-rng is registered first, via-rng second
2.6.37-rc7-without+modprobe.dmesg:
	2.6.37-rc7 with 84c164a34ffe67908a reverted, b43 blacklisted and
	manually modprobed after via-rng, crashing
	via-rng is registered first, b43-rng second

Seems like the crash shows up when b43-rng is registered second, but not
when via-rng is registered second.
Btw.: `cat rng_available' does also not crash when via-rng is registered
second.


regards
   Mario
From: Larry Finger
Date: Thursday, December 30, 2010 - 3:49 pm

Added the two listed maintainers for hardware randon-number generators and
dropped the wireless and b43 lists.

Matt and Herbert:

There is a regression in 2.6.37-rcX relative to 2.6.36. The problem shows as the
following kernel BUG:

[   30.313362] BUG: unable to handle kernel paging request at 60870667
[   30.313372] IP: [<f8f4e3df>] hwrng_register+0x5f/0x14d [rng_core]
[   30.313391] *pdpt = 0000000036c34001 *pde = 0000000000000000
[   30.313403] Oops: 0000 [#1] SMP
[   30.313411] last sysfs file: /sys/module/bluetooth/initstate
[   30.313420] Modules linked in: l2cap crc16 parport_pc ppdev lp parport sbs
sbshc power_meter pci_slot hed fan container acpi_cpufreq mperf
cpufreq_conservative cpufreq_userspace cpufreq_stats cpufreq_powersave dm_crypt
fuse loop eeprom via_cputemp i2c_dev nvram padlock_aes aes_i586 aes_generic
padlock_sha sha256_generic sha1_generic via_rng msr cpuid snd_hda_codec_realtek
snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss arc4 snd_pcm ecb
snd_seq_midi snd_rawmidi snd_seq_midi_event b43 snd_seq snd_timer rng_core
uvcvideo video snd_seq_device joydev mac80211 videodev ideapad_laptop output
btusb battery processor bluetooth tpm_tis snd v4l1_compat ac tpm wmi
power_supply cfg80211 soundcore snd_page_alloc tpm_bios rfkill button shpchp
pcspkr i2c_viapro evdev i2c_core psmouse serio_raw pci_hotplug ext3 jbd mbcache
raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy
async_tx raid1 raid0 multipath linear md_mod dm_mirror dm_region_hash dm_log
dm_mod btrfs zlib_deflate crc32c libcrc32c sd_mod crc_t10dif ata_generic
pata_via libata uhci_hcd ssb ehci_hcd tg3 via_sdmmc usbcore scsi_mod pcmcia
thermal mmc_core pcmcia_core libphy thermal_sys nls_base [last unloaded:
scsi_wait_scan]
[   30.313670]
[   30.313681] Pid: 1742, comm: NetworkManager Not tainted 2.6.37-rc7-self #3
MoutCook/20021,2959
[   30.313692] EIP: 0060:[<f8f4e3df>] EFLAGS: 00010216 CPU: 0
[   30.313706] EIP is at hwrng_register+0x5f/0x14d [rng_core]
[   ...
From: Mario 'BitKoenig' Holbe
Date: Thursday, December 30, 2010 - 4:17 pm

I believe I can confirm the bug does not directly belong to b43:
I created a second via-rng driver (just copied via-rng.c to via-rng2.c
and changed the via_rng.name) and modprobed it. I blacklisted b43 to
keep it out of the game.

Virtually the same crash dump as with b43 shows up when I modprobe
via-rng2 after via-rng is loaded already.

Attached is a dmesg excerpt from a 2.6.37-rc7 kernel built with Larrys
hwrng_debug patch applied (which basically calls dump_stack() in
hwrng_register()).

objdump of hw_random/core.o:

00000380 <hwrng_register>:
hwrng_register():
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:299
 380:   56                      push   %esi
...
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:315
 3d9:   8b 76 1c                mov    0x1c(%esi),%esi
 3dc:   83 ee 1c                sub    $0x1c,%esi
prefetch():
/tmp/1/linux-source-2.6.37-rc7/arch/x86/include/asm/processor.h:837
 3df:   8b 46 1c                mov    0x1c(%esi),%eax
 3e2:   8d 74 26 00             lea    0x0(%esi,%eiz,1),%esi
hwrng_register():
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:315
 3e6:   81 fe f8 ff ff ff       cmp    $0xfffffff8,%esi

hw_random/core.c:
   313          /* Must not register two RNGs with the same name. */
   314          err = -EEXIST;
   315          list_for_each_entry(tmp, &rng_list, list) {
   316                  if (strcmp(tmp->name, rng->name) == 0)
   317                          goto out_unlock;
   318          }


Larry: Thanks for your help!


regards
   Mario
-- 
Goethe war nicht gerne Minister. Er beschaeftigte sich lieber geistig.
                                            -- Lukasburger Stilblueten
From: Herbert Xu
Date: Thursday, December 30, 2010 - 5:37 pm

My suspicion is that VIA's xstore is writing more than 4 bytes as
the list pointer happens to lie immediately after rng->priv which
is where xstore is writing to.

Harald, do you know whether this is documented or is this a known
errata item?

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--

From: Larry Finger
Date: Thursday, December 30, 2010 - 5:46 pm

The following patch should be able to test if xstore is overwriting the list
pointer.

Larry
---

Index: wireless-testing/include/linux/hw_random.h
===================================================================
--- wireless-testing.orig/include/linux/hw_random.h
+++ wireless-testing/include/linux/hw_random.h
@@ -38,6 +38,7 @@ struct hwrng {
 	int (*data_read)(struct hwrng *rng, u32 *data);
 	int (*read)(struct hwrng *rng, void *data, size_t max, bool wait);
 	unsigned long priv;
+	char junk[12];

 	/* internal. */
 	struct list_head list;


From: Mario 'BitKoenig' Holbe
Date: Thursday, December 30, 2010 - 7:25 pm

Confirmed. No crashes with the junk buffer in action.
I applied both patches (dump_stack() in hwrng_register() and junk[]
after priv data) to vanilla 2.6.37-rc7 and tested both: via-rng and my
via+rng2 as well as via-rng and b43-rng - no crashes. The (previously
also crashing) `cat rng_available' does survive as well:

$ cat /sys/devices/virtual/misc/hw_random/rng_available
via b43_phy0 via2 
$ 

Attached 2 dmesg excerpts.


regards & g'nite
   Mario
-- 
Tower: "Say fuelstate." Pilot: "Fuelstate."
Tower: "Say again." Pilot: "Again."
Tower: "Arghl, give me your fuel!" Pilot: "Sorry, need it by myself..."
From: Herbert Xu
Date: Thursday, December 30, 2010 - 7:46 pm

Thanks for checking.  Can you provide the output of

	cat /proc/cpuinfo

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--

From: Mario 'BitKoenig' Holbe
Date: Friday, December 31, 2010 - 1:51 am

attached.


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
From: Herbert Xu
Date: Monday, January 3, 2011 - 9:33 pm

Thanks.

Can you please test the following patch?

diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
index 794aacb..507a57f 100644
--- a/drivers/char/hw_random/via-rng.c
+++ b/drivers/char/hw_random/via-rng.c
@@ -24,6 +24,7 @@
  * warranty of any kind, whether express or implied.
  */
 
+#include <crypto/padlock.h>
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/hw_random.h>
@@ -34,7 +35,6 @@
 #include <asm/i387.h>
 
 
-#define PFX	KBUILD_MODNAME ": "
 
 
 enum {
@@ -90,8 +90,10 @@ static inline u32 xstore(u32 *addr, u32 edx_in)
 
 static int via_rng_data_present(struct hwrng *rng, int wait)
 {
+	char buf[16 + PADLOCK_ALIGNMENT - STACK_ALIGN] __attribute__
+		((aligned(STACK_ALIGN)));
+	u32 *via_rng_datum = (u32 *)PTR_ALIGN(&buf[0], PADLOCK_ALIGNMENT);
 	u32 bytes_out;
-	u32 *via_rng_datum = (u32 *)(&rng->priv);
 	int i;
 
 	/* We choose the recommended 1-byte-per-instruction RNG rate,
@@ -115,6 +117,7 @@ static int via_rng_data_present(struct hwrng *rng, int wait)
 			break;
 		udelay(10);
 	}
+	rng->priv = *via_rng_datum;
 	return bytes_out ? 1 : 0;
 }
 
diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index 2e992bc..2e56508 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -9,6 +9,7 @@
 
 #include <crypto/algapi.h>
 #include <crypto/aes.h>
+#include <crypto/padlock.h>
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/types.h>
@@ -21,7 +22,6 @@
 #include <asm/byteorder.h>
 #include <asm/processor.h>
 #include <asm/i387.h>
-#include "padlock.h"
 
 /*
  * Number of data blocks actually fetched for each xcrypt insn.
diff --git a/drivers/crypto/padlock-sha.c b/drivers/crypto/padlock-sha.c
index d3a27e0..adf075b 100644
--- a/drivers/crypto/padlock-sha.c
+++ b/drivers/crypto/padlock-sha.c
@@ -13,6 +13,7 @@
  */
 
 #include <crypto/internal/hash.h>
+#include <crypto/padlock.h>
 #include <crypto/sha.h>
 #include ...
From: Mario 'BitKoenig' Holbe
Date: Tuesday, January 4, 2011 - 5:19 am

Hello Herbert,


Hmmm, yes - the patch fixes the crashes, i.e. no more crashes with
either sequence of module-loading, cat rng_available works as well,
but...

Having this patch active rngd complains:
	rngd[1435]: rngd 2-unofficial-mt.13 starting up...
	rngd[1435]: block failed FIPS test: 0x1f
	rngd[1435]: block failed FIPS test: 0x1f
	...
	rngd[1435]: stats: entropy added to kernel pool: 0
	rngd[1435]: stats: FIPS 140-2 successes: 0
	rngd[1435]: stats: FIPS 140-2 failures: 10

It doesn't do this without the patch.
The only available rng was via, I did blacklist the others just to be
sure.


regards
   Mario
-- 
The social dynamics of the net are a direct consequence of the fact that
nobody has yet developed a Remote Strangulation Protocol.  -- Larry Wall
From: Herbert Xu
Date: Tuesday, January 4, 2011 - 5:38 am

Hmm, can you print out what it's actually producing (e.g., by
stracing rngd)?

Can you also double-check that this doesn't happen with Larry's
patch?

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--

From: Mario 'BitKoenig' Holbe
Date: Tuesday, January 4, 2011 - 5:57 am

# ps -ef | grep 'rng[d]'
# cat /sys/devices/virtual/misc/hw_random/rng_available
via 
# hexdump -n 512 -C /dev/hwrng
00000000  00 ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000010  ff ff ff ff ff ff ff 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200
# hexdump -n 512 -C /dev/hwrng
00000000  00 ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200
# hexdump -n 1024 -C /dev/hwrng
00000000  00 ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000060  ff ff ff ff 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400
# hexdump -n 1024 -C /dev/hwrng
00000000  00 ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000070  ff 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400

Nope, it doesn't do this with Larry's patch.


Mario
-- 
The Encyclopedia Galactica, in its chapter on Love states that it is far
too complicated to define.
The Hitchhiker's Guide to the Galaxy has this to say on the subject of
love: Avoid, if at all possible.
From: Herbert Xu
Date: Tuesday, January 4, 2011 - 3:42 pm

Weird.

Can you please try this patch against vanilla to print out the
raw output of xstore?

diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
index 794aacb..4408d4e 100644
--- a/drivers/char/hw_random/via-rng.c
+++ b/drivers/char/hw_random/via-rng.c
@@ -24,6 +24,7 @@
  * warranty of any kind, whether express or implied.
  */
 
+#include <crypto/padlock.h>
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/hw_random.h>
@@ -34,7 +35,6 @@
 #include <asm/i387.h>
 
 
-#define PFX	KBUILD_MODNAME ": "
 
 
 enum {
@@ -85,13 +85,16 @@ static inline u32 xstore(u32 *addr, u32 edx_in)
 		:"D"(addr), "d"(edx_in));
 
 	irq_ts_restore(ts_state);
+	printk(KERN_DEBUG "0x%x\n", *addr);
 	return eax_out;
 }
 
 static int via_rng_data_present(struct hwrng *rng, int wait)
 {
+	char buf[16 + PADLOCK_ALIGNMENT - STACK_ALIGN] __attribute__
+		((aligned(STACK_ALIGN)));
+	u32 *via_rng_datum = (u32 *)PTR_ALIGN(&buf[0], PADLOCK_ALIGNMENT);
 	u32 bytes_out;
-	u32 *via_rng_datum = (u32 *)(&rng->priv);
 	int i;
 
 	/* We choose the recommended 1-byte-per-instruction RNG rate,
@@ -115,6 +118,7 @@ static int via_rng_data_present(struct hwrng *rng, int wait)
 			break;
 		udelay(10);
 	}
+	rng->priv = *via_rng_datum;
 	return bytes_out ? 1 : 0;
 }
 
diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index 2e992bc..2e56508 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -9,6 +9,7 @@
 
 #include <crypto/algapi.h>
 #include <crypto/aes.h>
+#include <crypto/padlock.h>
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/types.h>
@@ -21,7 +22,6 @@
 #include <asm/byteorder.h>
 #include <asm/processor.h>
 #include <asm/i387.h>
-#include "padlock.h"
 
 /*
  * Number of data blocks actually fetched for each xcrypt insn.
diff --git a/drivers/crypto/padlock-sha.c b/drivers/crypto/padlock-sha.c
index d3a27e0..adf075b 100644
--- ...
From: Mario 'BitKoenig' Holbe
Date: Tuesday, January 4, 2011 - 4:06 pm

# ps -ef | grep 'rng[d]'
# cat /sys/devices/virtual/misc/hw_random/rng_available
via 
# hexdump -n 16 -C /dev/hwrng
00000000  00 ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000010
# 

kern.log meanwhile (lines numbered):
     1  Jan  4 23:56:40 ideapad kernel: [  151.714225] 0x0
     2  Jan  4 23:56:40 ideapad kernel: [  151.714236] 0xffffffff
     3  Jan  4 23:56:40 ideapad kernel: [  151.714239] 0x0
     4  Jan  4 23:56:40 ideapad kernel: [  151.714251] 0xffffffff
...
   233  Jan  4 23:56:40 ideapad kernel: [  151.715967] 0x0
   234  Jan  4 23:56:40 ideapad kernel: [  151.715980] 0xffffffff
   235  Jan  4 23:56:40 ideapad kernel: [  151.715982] 0x0
   236  Jan  4 23:56:40 ideapad kernel: [  151.715995] 0xffffffff
   237  Jan  4 23:56:40 ideapad kernel: [  151.720342] 0x0
   238  Jan  4 23:56:40 ideapad kernel: [  151.720347] 0x0
   239  Jan  4 23:56:40 ideapad kernel: [  151.720361] 0x0
   240  Jan  4 23:56:40 ideapad kernel: [  151.720365] 0x0
...
  8163  Jan  4 23:56:40 ideapad kernel: [  151.987049] 0x0
  8164  Jan  4 23:56:40 ideapad kernel: [  151.987061] 0x0
  8165  Jan  4 23:56:40 ideapad kernel: [  151.987063] 0x0
  8166  Jan  4 23:56:40 ideapad kernel: [  151.987075] 0x0


Mario
-- 
If her DNA was off by one percentage point, she'd be a dolphin.
                                -- Dr. Gregory House
From: Larry Finger
Date: Thursday, December 30, 2010 - 7:25 pm

AFAIK, he is building with the mainline 2.6.37-rc7/8 tree from Linus, thus the
build should be clean, but thanks for the heads-up.

In an Email from Herbert Xu that did not go to the wireless or b43 lists, it is
suspected that the xstore command on a VIA CPU might generate more than 4 bytes
of output and clobber the list header. We now also know that a second copy of
via-rng will also fail, thus b43 is cleared.

Larry
--

From: Michael Büsch
Date: Thursday, December 30, 2010 - 6:57 pm

I suspect that there is some "hw_random.h" header version mixup is going
on here. The layout of struct hwrng was changed recently.

Your crash seems to happen on the list head embedded in struct hwrng.

Please make sure that your build environment is clean and you're not
using any external stuff such as compat-wireless. All of hwrng-core,
rng-via and b43 must be compiled against the same hw_random.h.

-- 
Greetings Michael.

--

Previous thread: IOMMU and DMA mode of pata_jmicron by Steffen Moser on Tuesday, December 28, 2010 - 4:43 pm. (5 messages)

Next thread: [PATCH] usb: pch_udc: Fixed issue which does not work with g_serial by Toshiharu Okada on Tuesday, December 28, 2010 - 6:07 pm. (1 message)