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

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

[Larry Finger]

Mario Holbe wrote:

> on 2.6.37-rc7 the b43 driver crashes in hwrng_register(). This makes the
> system virtually unusable since it appears to block networking syscalls.
> This leads to, for example, ifconfig never return.
> This issue does also exist in 2.6.37-rc5.
> This issue does not exist in 2.6.36.2.
>
> The hardware in question is:
> 02:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g
LP-PHY [14e4:4315] (rev 01)
> on a Lenovo Ideapad S12 with VIA Nano.

> dmesg excerpt:
> [ 2.056847] b43-pci-bridge 0000:02:00.0: PCI INT A -> GSI 28 (level, low) ->
IRQ 28
> [ 2.056864] b43-pci-bridge 0000:02:00.0: setting latency timer to 64
...
> [ 8.643695] b43-phy0: Broadcom 4312 WLAN found (core revision 15)
> [ 9.047514] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> [ 9.048441] Registered led device: b43-phy0::tx
> [ 9.048479] Registered led device: b43-phy0::rx
> [ 9.048518] Registered led device: b43-phy0::radio
> [ 9.048542] Broadcom 43xx driver loaded [ Features: PMLS, Firmware-ID: FW13 ]
...
> [ 24.312100] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
...
> [ 29.848400] b43-pci-bridge 0000:02:00.0: PCI: Disallowing DAC for device
> [ 29.848407] b43-phy0: DMA mask fallback from 64-bit to 32-bit
> [ 29.868632] BUG: unable to handle kernel paging request at 907cde0c
> [ 29.868640] IP: [<f8d543cc>] hwrng_register+0x4c/0x139 [rng_core]
> [ 29.868655] *pde = 00000000
> [ 29.868659] Oops: 0000 [#1] SMP
> [ 29.868664] last sysfs file: /sys/bus/pci/drivers/parport_pc/uevent
> [ 29.868670] Modules linked in: 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 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
libphy thermal thermal_sys nls_base [last unloaded: scsi_wait_scan]
> [ 29.868810]
> [ 29.868816] Pid: 1781, comm: NetworkManager Not tainted 2.6.37-rc7-686 #1
MoutCook/20021,2959
> [ 29.868822] EIP: 0060:[<f8d543cc>] EFLAGS: 00010286 CPU: 0
> [ 29.868829] EIP is at hwrng_register+0x4c/0x139 [rng_core]
> [ 29.868834] EAX: 00000001 EBX: f4b17010 ECX: f6e5db6c EDX: f4b17035
> [ 29.868839] ESI: 907cddf0 EDI: 00000000 EBP: 00000036 ESP: f6e5db54
> [ 29.868844] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [ 29.868850] Process NetworkManager (pid: 1781, ti=f6e5c000 task=f6eb6080
task.ti=f6e5c000)
> [ 29.868854] Stack:
> [ 29.868856] f4b16fc0 f4b17035 f8e5a870 f4b17035 0000001f f8e70095 f8e6f9ca
f4b71e70
> [ 29.868866] 0000000f f6c95000 f6c95000 f6e97400 f4b162c0 f4b10240 f4b16fc8
f8e5ad67
> [ 29.868875] f89e43da f4b162c0 f6cab400 f8b80e44 f6cab000 f8b70889 f8b6fe7a
00000000
> [ 29.868884] Call Trace:
> [ 29.868909] [<f8e5a870>] ? b43_wireless_core_init+0xd0c/0xdd6 [b43]
> [ 29.868925] [<f8e5ad67>] ? b43_op_start+0xf8/0x142 [b43]
> [ 29.868947] [<f89e43da>] ? cfg80211_netdev_notifier_call+0x342/0x355 [cfg80211]
> [ 29.868984] [<f8b70889>] ? ieee80211_do_open+0xed/0x45f [mac80211]
> [ 29.869002] [<f8b6fe7a>] ? ieee80211_check_concurrent_iface+0x1c/0x135 [mac80211]
> [ 29.869015] [<c11edcba>] ? __dev_open+0x7d/0xa7
> [ 29.869022] [<c11ec683>] ? __dev_change_flags+0x9a/0x10d
> [ 29.869028] [<c11edc12>] ? dev_change_flags+0x10/0x3b
> [ 29.869036] [<c11f7c77>] ? do_setlink+0x23e/0x532
> [ 29.869044] [<c11f803b>] ? rtnl_setlink+0xd0/0xe1
> [ 29.869058] [<c1145b00>] ? __strncpy_from_user+0x1d/0x2b
> [ 29.869064] [<c11f7f6b>] ? rtnl_setlink+0x0/0xe1
> [ 29.869069] [<c11f77a2>] ? rtnetlink_rcv_msg+0x186/0x19c
> [ 29.869075] [<c11f761c>] ? rtnetlink_rcv_msg+0x0/0x19c
> [ 29.869082] [<c1206818>] ? netlink_rcv_skb+0x2d/0x72
> [ 29.869088] [<c11f7616>] ? rtnetlink_rcv+0x18/0x1e
> [ 29.869093] [<c120666c>] ? netlink_unicast+0xba/0x10e
> [ 29.869099] [<c1207170>] ? netlink_sendmsg+0x23d/0x256
> [ 29.869111] [<c11dfe26>] ? __sock_sendmsg+0x48/0x4e
> [ 29.869117] [<c11e008f>] ? sock_sendmsg+0x78/0x8f
> [ 29.869123] [<c11e008f>] ? sock_sendmsg+0x78/0x8f
> [ 29.869131] [<c10c6785>] ? d_kill+0x38/0x3d
> [ 29.869141] [<c11e7f0c>] ? verify_iovec+0x3d/0x79
> [ 29.869147] [<c11e088d>] ? sys_sendmsg+0x15f/0x1c1
> [ 29.869153] [<c11e04c4>] ? sockfd_lookup_light+0x13/0x3f
> [ 29.869160] [<c11e0b25>] ? sys_sendto+0xfd/0x121
> [ 29.869166] [<c11e43eb>] ? sk_prot_alloc+0x62/0xd6
> [ 29.869174] [<c1001e6e>] ? __switch_to+0x6f/0xe2
> [ 29.869183] [<c12860de>] ? schedule+0x579/0x5b6
> [ 29.869190] [<c11e0723>] ? sys_recvmsg+0x3c/0x47
> [ 29.869196] [<c11e1afd>] ? sys_socketcall+0x17f/0x1cb
> [ 29.869202] [<c1002f9f>] ? sysenter_do_call+0x12/0x28
> [ 29.869206] Code: f8 e8 46 25 53 c8 8b 35 ec 45 d5 f8 eb 1a 8b 13 8b 06 e8 17
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
0f 18 00 90 81 fe d0 45 d5 f8 75 d4 83 3d ec 47 d5 f8
> [ 29.869249] EIP: [<f8d543cc>] hwrng_register+0x4c/0x139 [rng_core] SS:ESP
0068:f6e5db54
> [ 29.869259] CR2: 00000000907cde0c
> [ 29.869264] ---[ end trace 6719399ed79e8cc1 ]---

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

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1.1: Type: text/plain, Size: 3124 bytes --]

Hello Larry,

On Tue, Dec 28, 2010 at 06:34:08PM -0600, Larry Finger wrote:
> Mario Holbe wrote:
> > on 2.6.37-rc7 the b43 driver crashes in hwrng_register(). This makes the
...
> > This issue does also exist in 2.6.37-rc5.
> > This issue does not exist in 2.6.36.2.
...
> > [ 29.868632] BUG: unable to handle kernel paging request at 907cde0c
> > [ 29.868640] IP: [<f8d543cc>] hwrng_register+0x4c/0x139 [rng_core]
...
> > [ 29.868884] Call Trace:
> > [ 29.868909] [<f8e5a870>] ? b43_wireless_core_init+0xd0c/0xdd6 [b43]
> 
> I almost missed this posting.

You're welcome :)

> Please post wireless problems with
> linux-wireless@vger.kernel.org for better visibility.

Sorry and thanks for completing the CC: list.

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

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

[-- Attachment #1.2: 2.6.36.2.rng_available-crash.dmesg --]
[-- Type: text/plain, Size: 3304 bytes --]

[  389.303538] BUG: unable to handle kernel paging request at 288dcb5b
[  389.303553] IP: [<f8dda34c>] hwrng_attr_available_show+0x5c/0x90 [rng_core]
[  389.303582] *pde = 00000000 
[  389.303591] Oops: 0000 [#1] SMP 
[  389.303599] last sysfs file: /sys/devices/virtual/misc/hw_random/rng_available
[  389.303609] Modules linked in: uinput via drm sco bnep rfcomm 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 snd_pcm arc4 joydev ecb snd_seq_midi b43 rng_core snd_rawmidi snd_seq_midi_event mac80211 snd_seq uvcvideo video snd_timer cfg80211 snd_seq_device videodev v4l1_compat ideapad_laptop snd btusb i2c_viapro led_class sparse_keymap bluetooth tpm_tis tpm wmi output i2c_core battery tpm_bios shpchp processor ac soundcore rfkill pcspkr pci_hotplug snd_page_alloc psmouse button serio_raw evdev 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 ehci_hcd ssb scsi_mod usbcore tg3 via_sdmmc pcmcia mmc_core libphy thermal thermal_sys pcmcia_core nls_base [last unloaded: scsi_wait_scan]
[  389.303871] 
[  389.303882] Pid: 3004, comm: cat Not tainted 2.6.36.2 #1 MoutCook/20021,2959
[  389.303893] EIP: 0060:[<f8dda34c>] EFLAGS: 00010216 CPU: 0
[  389.303908] EIP is at hwrng_attr_available_show+0x5c/0x90 [rng_core]
[  389.303918] EAX: f5da2000 EBX: 288dcb3f ECX: 00000ff1 EDX: f8dda571
[  389.303928] ESI: f5da2000 EDI: 0000000d EBP: 00000fff ESP: f6841f30
[  389.303937]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  389.303948] Process cat (pid: 3004, ti=f6840000 task=f5c9f180 task.ti=f6840000)
[  389.303955] Stack:
[  389.303960]  f8dda618 fffffffb f8dda2f0 c12b1834 c11bd17e f5ccaf40 f69fe330 f6841f9c
[  389.303978] <0> c10f8244 f5d9bcc0 f5ccaf54 f69c7e08 09a66000 00008000 f5d9bcc0 09a66000
[  389.303997] <0> c10f81b8 f6841f9c c10b7774 f6841f9c c1282259 f5d9bcc0 fffffff7 09a66000
[  389.304015] Call Trace:
[  389.304015]  [<f8dda2f0>] ? hwrng_attr_available_show+0x0/0x90 [rng_core]
[  389.304015]  [<c11bd17e>] ? dev_attr_show+0x16/0x32
[  389.304015]  [<c10f8244>] ? sysfs_read_file+0x8c/0xf5
[  389.304015]  [<c10f81b8>] ? sysfs_read_file+0x0/0xf5
[  389.304015]  [<c10b7774>] ? vfs_read+0x7c/0xd6
[  389.304015]  [<c1282259>] ? do_page_fault+0x26d/0x2cf
[  389.304015]  [<c10b7861>] ? sys_read+0x3c/0x60
[  389.304015]  [<c1002f1f>] ? sysenter_do_call+0x12/0x28
[  389.304015] Code: e9 89 f0 29 f9 e8 ef 63 36 c8 8b 03 e8 60 64 36 c8 89 e9 ba 71 a5 dd f8 8d 3c 38 89 f0 29 f9 47 e8 d4 63 36 c8 8b 5b 1c 83 eb 1c <8b> 43 1c 0f 18 00 90 81 fb d0 a5 dd f8 75 c3 b9 ff 0f 00 00 ba 
[  389.304015] EIP: [<f8dda34c>] hwrng_attr_available_show+0x5c/0x90 [rng_core] SS:ESP 0068:f6841f30
[  389.304015] CR2: 00000000288dcb5b
[  389.304311] ---[ end trace a1f28568aee0d057 ]---

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Larry Finger]

[-- Attachment #1: Type: text/plain, Size: 3312 bytes --]

On 12/29/2010 01:54 PM, Mario 'BitKoenig' Holbe wrote:
> Hello Larry,
> 
> On Tue, Dec 28, 2010 at 06:34:08PM -0600, Larry Finger wrote:
>> Mario Holbe wrote:
>>> on 2.6.37-rc7 the b43 driver crashes in hwrng_register(). This makes the
> ...
>>> This issue does also exist in 2.6.37-rc5.
>>> This issue does not exist in 2.6.36.2.
> ...
>>> [ 29.868632] BUG: unable to handle kernel paging request at 907cde0c
>>> [ 29.868640] IP: [<f8d543cc>] hwrng_register+0x4c/0x139 [rng_core]
> ...
>>> [ 29.868884] Call Trace:
>>> [ 29.868909] [<f8e5a870>] ? b43_wireless_core_init+0xd0c/0xdd6 [b43]
>>
>> I almost missed this posting.
> 
> You're welcome :)
> 
>> Please post wireless problems with
>> linux-wireless@vger.kernel.org for better visibility.
> 
> Sorry and thanks for completing the CC: list.
> 
>> 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.
> 
> 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).

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

[-- Attachment #2: b43_fix_hwrng_not_enabled --]
[-- Type: text/plain, Size: 1599 bytes --]

Index: wireless-testing/drivers/net/wireless/b43/main.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -3142,19 +3142,19 @@ static int b43_rng_read(struct hwrng *rn
 }
 #endif /* CONFIG_B43_HWRNG */
 
+#ifdef CONFIG_B43_HWRNG
 static void b43_rng_exit(struct b43_wl *wl)
 {
-#ifdef CONFIG_B43_HWRNG
 	if (wl->rng_initialized)
 		hwrng_unregister(&wl->rng);
-#endif /* CONFIG_B43_HWRNG */
 }
+#endif /* CONFIG_B43_HWRNG */
 
+#ifdef CONFIG_B43_HWRNG
 static int b43_rng_init(struct b43_wl *wl)
 {
 	int err = 0;
 
-#ifdef CONFIG_B43_HWRNG
 	snprintf(wl->rng_name, ARRAY_SIZE(wl->rng_name),
 		 "%s_%s", KBUILD_MODNAME, wiphy_name(wl->hw->wiphy));
 	wl->rng.name = wl->rng_name;
@@ -3167,10 +3167,10 @@ static int b43_rng_init(struct b43_wl *w
 		b43err(wl, "Failed to register the random "
 		       "number generator (%d)\n", err);
 	}
-#endif /* CONFIG_B43_HWRNG */
 
 	return err;
 }
+#endif /* CONFIG_B43_HWRNG */
 
 static void b43_tx_work(struct work_struct *work)
 {
@@ -4288,8 +4288,10 @@ static void b43_wireless_core_exit(struc
 	if (!dev || b43_status(dev) != B43_STAT_INITIALIZED)
 		return;
 
+#ifdef CONFIG_B43_HWRNG
 	/* Unregister HW RNG driver */
 	b43_rng_exit(dev->wl);
+#endif
 
 	b43_set_status(dev, B43_STAT_UNINIT);
 
@@ -4420,8 +4422,10 @@ static int b43_wireless_core_init(struct
 
 	b43_set_status(dev, B43_STAT_INITIALIZED);
 
+#ifdef CONFIG_B43_HWRNG
 	/* Register HW RNG driver */
 	b43_rng_init(dev->wl);
+#endif
 
 out:
 	return err;

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

On Wed, Dec 29, 2010 at 06:30:40PM -0600, Larry Finger wrote:
> On 12/29/2010 01:54 PM, Mario 'BitKoenig' Holbe wrote:
> > 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.
> 
> Please show the output of "egrep "B43|RNG|RANDOM" .config".

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
CONFIG_CRYPTO_DEV_HIFN_795X_RNG=y

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Larry Finger]

On 12/29/2010 07:20 PM, Mario 'BitKoenig' Holbe wrote:
> 
> 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 :)

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

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1: Type: text/plain, Size: 3066 bytes --]

On Wed, Dec 29, 2010 at 08:37:10PM -0600, Larry Finger wrote:
> 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.

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    0x0(%esi,%eiz,1),%esi
hwrng_attr_available_show():
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:245

   245		list_for_each_entry(rng, &rng_list, list) {
   246			strncat(buf, rng->name, PAGE_SIZE - ret - 1);
   247			ret += strlen(rng->name);
   248			strncat(buf, " ", PAGE_SIZE - ret - 1);
   249			ret++;
   250		}


regards
   Mario
-- 
The problem in the world today is communication. Too much communication.
                                                     -- Homer J. Simpson

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Larry Finger]

[-- Attachment #1: Type: text/plain, Size: 3281 bytes --]

On 12/30/2010 08:34 AM, Mario 'BitKoenig' Holbe wrote:
> On Wed, Dec 29, 2010 at 08:37:10PM -0600, Larry Finger wrote:
>> 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.
> 
> 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    0x0(%esi,%eiz,1),%esi
> hwrng_attr_available_show():
> /tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:245
> 
>    245		list_for_each_entry(rng, &rng_list, list) {
>    246			strncat(buf, rng->name, PAGE_SIZE - ret - 1);
>    247			ret += strlen(rng->name);
>    248			strncat(buf, " ", PAGE_SIZE - ret - 1);
>    249			ret++;
>    250		}

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




[-- Attachment #2: hwrng_debug --]
[-- Type: text/plain, Size: 822 bytes --]

Index: wireless-testing/drivers/char/hw_random/core.c
===================================================================
--- wireless-testing.orig/drivers/char/hw_random/core.c
+++ wireless-testing/drivers/char/hw_random/core.c
@@ -49,11 +49,11 @@
 
 
 static struct hwrng *current_rng;
-static LIST_HEAD(rng_list);
 static DEFINE_MUTEX(rng_mutex);
 static int data_avail;
 static u8 rng_buffer[SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES]
 	__cacheline_aligned;
+static LIST_HEAD(rng_list);
 
 static inline int hwrng_init(struct hwrng *rng)
 {
@@ -305,6 +305,9 @@ int hwrng_register(struct hwrng *rng)
 	    (rng->data_read == NULL && rng->read == NULL))
 		goto out;
 
+	printk(KERN_INFO "Calling hwrng_register\n");
+	dump_stack();
+
 	mutex_lock(&rng_mutex);
 
 	/* Must not register two RNGs with the same name. */

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1.1: Type: text/plain, Size: 1207 bytes --]

On Thu, Dec 30, 2010 at 12:37:21PM -0600, Larry Finger wrote:
> 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.

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
-- 
> As Luke Leighton said once on samba-ntdom, "now, what was that about
> rebooting?   that was so long ago, i had to look it up with man -k."

[-- Attachment #1.2: 2.6.37-rc7-vanilla.dmesg --]
[-- Type: text/plain, Size: 8087 bytes --]

[    2.048695] b43-pci-bridge 0000:02:00.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
[    2.048713] b43-pci-bridge 0000:02:00.0: setting latency timer to 64
...
[    8.626419] b43-phy0: Broadcom 4312 WLAN found (core revision 15)
[    8.805909] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[    8.806815] Registered led device: b43-phy0::tx
[    8.806853] Registered led device: b43-phy0::rx
[    8.806894] Registered led device: b43-phy0::radio
[    8.806915] Broadcom 43xx driver loaded [ Features: PMLS, Firmware-ID: FW13 ]
[   11.977267] VIA RNG detected
[   11.977272] Calling hwrng_register
[   11.977278] Pid: 889, comm: modprobe Not tainted 2.6.37-rc7-self #3
[   11.977282] Call Trace:
[   11.977295]  [<f8f4e3ac>] ? hwrng_register+0x2c/0x14d [rng_core]
[   11.977303]  [<f9246023>] ? mod_init+0x23/0x3b [via_rng]
[   11.977312]  [<c1003069>] ? do_one_initcall+0x68/0x10f
[   11.977323]  [<c105f0d3>] ? sys_init_module+0xca5/0xe36
[   11.977354]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28
...
[   24.752102] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
...
[   30.292235] b43-pci-bridge 0000:02:00.0: PCI: Disallowing DAC for device
[   30.292246] b43-phy0: DMA mask fallback from 64-bit to 32-bit
[   30.312705] Calling hwrng_register
[   30.312719] Pid: 1742, comm: NetworkManager Not tainted 2.6.37-rc7-self #3
[   30.312727] Call Trace:
[   30.312756]  [<f8f4e3ac>] ? hwrng_register+0x2c/0x14d [rng_core]
[   30.312799]  [<f8fab870>] ? b43_wireless_core_init+0xd0c/0xdd6 [b43]
[   30.312827]  [<f8fabd67>] ? b43_op_start+0xf8/0x142 [b43]
[   30.312866]  [<f8c273da>] ? cfg80211_netdev_notifier_call+0x342/0x355 [cfg80211]
[   30.312924]  [<f8e8e889>] ? ieee80211_do_open+0xed/0x45f [mac80211]
[   30.312956]  [<f8e8de7a>] ? ieee80211_check_concurrent_iface+0x1c/0x135 [mac80211]
[   30.312978]  [<c1203247>] ? __dev_open+0x7d/0xa7
[   30.312992]  [<c1201c10>] ? __dev_change_flags+0x9a/0x10d
[   30.313004]  [<c120319f>] ? dev_change_flags+0x10/0x3b
[   30.313020]  [<c120d207>] ? do_setlink+0x23e/0x532
[   30.313041]  [<c129ced6>] ? schedule+0x579/0x5b6
[   30.313052]  [<c120d5cb>] ? rtnl_setlink+0xd0/0xe1
[   30.313073]  [<c114f000>] ? clear_user+0x2b/0x43
[   30.313084]  [<c120d4fb>] ? rtnl_setlink+0x0/0xe1
[   30.313096]  [<c120cd32>] ? rtnetlink_rcv_msg+0x186/0x19c
[   30.313108]  [<c120cbac>] ? rtnetlink_rcv_msg+0x0/0x19c
[   30.313123]  [<c121bda8>] ? netlink_rcv_skb+0x2d/0x72
[   30.313134]  [<c120cba6>] ? rtnetlink_rcv+0x18/0x1e
[   30.313145]  [<c121bbfc>] ? netlink_unicast+0xba/0x10e
[   30.313156]  [<c121c700>] ? netlink_sendmsg+0x23d/0x256
[   30.313171]  [<c11f53a6>] ? __sock_sendmsg+0x48/0x4e
[   30.313181]  [<c11f560f>] ? sock_sendmsg+0x78/0x8f
[   30.313193]  [<c11f560f>] ? sock_sendmsg+0x78/0x8f
[   30.313207]  [<c10cf5dd>] ? d_kill+0x38/0x3d
[   30.313225]  [<c11fd48c>] ? verify_iovec+0x3d/0x79
[   30.313235]  [<c11f5e0d>] ? sys_sendmsg+0x15f/0x1c1
[   30.313247]  [<c11f5a44>] ? sockfd_lookup_light+0x13/0x3f
[   30.313258]  [<c11f60a5>] ? sys_sendto+0xfd/0x121
[   30.313273]  [<c10079ee>] ? __switch_to+0x6f/0xe2
[   30.313285]  [<c129ced6>] ? schedule+0x579/0x5b6
[   30.313296]  [<c11f5ca3>] ? sys_recvmsg+0x3c/0x47
[   30.313308]  [<c11f707d>] ? sys_socketcall+0x17f/0x1cb
[   30.313321]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28
[   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]
[   30.313715] EAX: 00000001 EBX: f4f13010 ECX: f8f4e589 EDX: f4f13035
[   30.313725] ESI: 6087064b EDI: 00000000 EBP: 00000036 ESP: f4fe7b54
[   30.313735]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[   30.313745] Process NetworkManager (pid: 1742, ti=f4fe6000 task=f6d2e8a0 task.ti=f4fe6000)
[   30.313753] Stack:
[   30.313757]  f4f12fc0 f4f13035 f8fab870 f4f13035 0000001f f8fc10bb f8fc09f0 f6dcce20
[   30.313775]  0000000f f6dcac00 f6dcac00 f6f27400 f4f122c0 f4f10240 f4f12fc8 f8fabd67
[   30.313793]  f8c273da f4f122c0 f6ec0400 f8e9ee48 f6ec0000 f8e8e889 f8e8de7a 00000000
[   30.313810] Call Trace:
[   30.313835]  [<f8fab870>] ? b43_wireless_core_init+0xd0c/0xdd6 [b43]
[   30.313863]  [<f8fabd67>] ? b43_op_start+0xf8/0x142 [b43]
[   30.313889]  [<f8c273da>] ? cfg80211_netdev_notifier_call+0x342/0x355 [cfg80211]
[   30.313926]  [<f8e8e889>] ? ieee80211_do_open+0xed/0x45f [mac80211]
[   30.313958]  [<f8e8de7a>] ? ieee80211_check_concurrent_iface+0x1c/0x135 [mac80211]
[   30.313975]  [<c1203247>] ? __dev_open+0x7d/0xa7
[   30.313986]  [<c1201c10>] ? __dev_change_flags+0x9a/0x10d
[   30.313998]  [<c120319f>] ? dev_change_flags+0x10/0x3b
[   30.314011]  [<c120d207>] ? do_setlink+0x23e/0x532
[   30.314026]  [<c129ced6>] ? schedule+0x579/0x5b6
[   30.314037]  [<c120d5cb>] ? rtnl_setlink+0xd0/0xe1
[   30.314052]  [<c114f000>] ? clear_user+0x2b/0x43
[   30.314063]  [<c120d4fb>] ? rtnl_setlink+0x0/0xe1
[   30.314074]  [<c120cd32>] ? rtnetlink_rcv_msg+0x186/0x19c
[   30.314086]  [<c120cbac>] ? rtnetlink_rcv_msg+0x0/0x19c
[   30.314098]  [<c121bda8>] ? netlink_rcv_skb+0x2d/0x72
[   30.314109]  [<c120cba6>] ? rtnetlink_rcv+0x18/0x1e
[   30.314120]  [<c121bbfc>] ? netlink_unicast+0xba/0x10e
[   30.314132]  [<c121c700>] ? netlink_sendmsg+0x23d/0x256
[   30.314145]  [<c11f53a6>] ? __sock_sendmsg+0x48/0x4e
[   30.314155]  [<c11f560f>] ? sock_sendmsg+0x78/0x8f
[   30.314167]  [<c11f560f>] ? sock_sendmsg+0x78/0x8f
[   30.314179]  [<c10cf5dd>] ? d_kill+0x38/0x3d
[   30.314192]  [<c11fd48c>] ? verify_iovec+0x3d/0x79
[   30.314203]  [<c11f5e0d>] ? sys_sendmsg+0x15f/0x1c1
[   30.314214]  [<c11f5a44>] ? sockfd_lookup_light+0x13/0x3f
[   30.314225]  [<c11f60a5>] ? sys_sendto+0xfd/0x121
[   30.314237]  [<c10079ee>] ? __switch_to+0x6f/0xe2
[   30.314250]  [<c129ced6>] ? schedule+0x579/0x5b6
[   30.314261]  [<c11f5ca3>] ? sys_recvmsg+0x3c/0x47
[   30.314272]  [<c11f707d>] ? sys_socketcall+0x17f/0x1cb
[   30.314284]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28
[   30.314292] Code: 34 c8 8b 35 1c e6 f4 f8 59 83 ee 1c eb 1d 8b 13 8b 06 e8 84 06 20 c8 85 c0 75 0a be ef ff ff ff e9 d3 00 00 00 8b 76 1c 83 ee 1c <8b> 46 1c 0f 18 00 90 81 fe 00 e6 f4 f8 75 d4 83 3d 2c e8 f4 f8 
[   30.314376] EIP: [<f8f4e3df>] hwrng_register+0x5f/0x14d [rng_core] SS:ESP 0068:f4fe7b54
[   30.314395] CR2: 0000000060870667
[   30.314404] ---[ end trace f498f4a4e1f00415 ]---

[-- Attachment #1.3: 2.6.37-rc7-without.dmesg --]
[-- Type: text/plain, Size: 2834 bytes --]

[    2.034921] b43-pci-bridge 0000:02:00.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
[    2.034939] b43-pci-bridge 0000:02:00.0: setting latency timer to 64
...
[    8.363363] b43-phy0: Broadcom 4312 WLAN found (core revision 15)
[    8.377768] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio2/input/input7
[    8.563088] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[    8.564034] Registered led device: b43-phy0::tx
[    8.564073] Registered led device: b43-phy0::rx
[    8.564111] Registered led device: b43-phy0::radio
[    8.564115] Calling hwrng_register
[    8.564121] Pid: 471, comm: modprobe Not tainted 2.6.37-rc7-self #4
[    8.564124] Call Trace:
[    8.564137]  [<f8fa83ac>] ? hwrng_register+0x2c/0x14d [rng_core]
[    8.564176]  [<f8fe0b23>] ? b43_probe+0x9e5/0xa85 [b43]
[    8.564189]  [<c11047aa>] ? sysfs_find_dirent+0x25/0x36
[    8.564195]  [<c11049dc>] ? __sysfs_add_one+0x25/0x72
[    8.564202]  [<c1104fb5>] ? sysfs_addrm_finish+0x13/0x8f
[    8.564208]  [<c11050e6>] ? sysfs_add_one+0x10/0xc7
[    8.564215]  [<c1105506>] ? sysfs_do_create_link+0x34/0x150
[    8.564246]  [<f859948d>] ? ssb_device_probe+0x2c/0x47 [ssb]
[    8.564258]  [<c11d9954>] ? driver_probe_device+0x8c/0x110
[    8.564264]  [<c11d9a18>] ? __driver_attach+0x40/0x5b
[    8.564273]  [<c11d91b5>] ? bus_for_each_dev+0x37/0x5f
[    8.564281]  [<c11d980a>] ? driver_attach+0x11/0x13
[    8.564287]  [<c11d99d8>] ? __driver_attach+0x0/0x5b
[    8.564293]  [<c11d9530>] ? bus_add_driver+0x87/0x1bb
[    8.564299]  [<c1148c2a>] ? kset_find_obj_hinted+0x12/0x7d
[    8.564317]  [<f9000000>] ? b43_init+0x0/0x62 [b43]
[    8.564323]  [<c11d9c34>] ? driver_register+0x7a/0xd9
[    8.564339]  [<f9000000>] ? b43_init+0x0/0x62 [b43]
[    8.564355]  [<f9000026>] ? b43_init+0x26/0x62 [b43]
[    8.564362]  [<c1003069>] ? do_one_initcall+0x68/0x10f
[    8.564372]  [<c105f0d3>] ? sys_init_module+0xca5/0xe36
[    8.564392]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28
[    8.564502] Broadcom 43xx driver loaded [ Features: PMLS, Firmware-ID: FW13 ]
...
[   11.786812] VIA RNG detected
[   11.786817] Calling hwrng_register
[   11.786823] Pid: 776, comm: modprobe Not tainted 2.6.37-rc7-self #4
[   11.786827] Call Trace:
[   11.786840]  [<f8fa83ac>] ? hwrng_register+0x2c/0x14d [rng_core]
[   11.786848]  [<f9202023>] ? mod_init+0x23/0x3b [via_rng]
[   11.786858]  [<c1003069>] ? do_one_initcall+0x68/0x10f
[   11.786868]  [<c105f0d3>] ? sys_init_module+0xca5/0xe36
[   11.786899]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28
...
[   24.596098] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
...
[   30.136244] b43-pci-bridge 0000:02:00.0: PCI: Disallowing DAC for device
[   30.136257] b43-phy0: DMA mask fallback from 64-bit to 32-bit
[   30.158623] ADDRCONF(NETDEV_UP): wlan0: link is not ready

[-- Attachment #1.4: 2.6.37-rc7-without+modprobe.dmesg --]
[-- Type: text/plain, Size: 6817 bytes --]

[    2.032560] b43-pci-bridge 0000:02:00.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
[    2.032577] b43-pci-bridge 0000:02:00.0: setting latency timer to 64
...
[   11.649390] VIA RNG detected
[   11.649395] Calling hwrng_register
[   11.649401] Pid: 745, comm: modprobe Not tainted 2.6.37-rc7-self #4
[   11.649405] Call Trace:
[   11.649415]  [<f90b13ac>] ? hwrng_register+0x2c/0x14d [rng_core]
[   11.649423]  [<f90be023>] ? mod_init+0x23/0x3b [via_rng]
[   11.649433]  [<c1003069>] ? do_one_initcall+0x68/0x10f
[   11.649443]  [<c105f0d3>] ? sys_init_module+0xca5/0xe36
[   11.649470]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28
...
[   92.861343] b43-phy0: Broadcom 4312 WLAN found (core revision 15)
[   92.986756] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   92.993027] Registered led device: b43-phy0::tx
[   92.993696] Registered led device: b43-phy0::rx
[   92.994271] Registered led device: b43-phy0::radio
[   92.994278] Calling hwrng_register
[   92.994284] Pid: 2622, comm: modprobe Not tainted 2.6.37-rc7-self #4
[   92.994287] Call Trace:
[   92.994312]  [<f90b13ac>] ? hwrng_register+0x2c/0x14d [rng_core]
[   92.994351]  [<f84b4b23>] ? b43_probe+0x9e5/0xa85 [b43]
[   92.994364]  [<c11047aa>] ? sysfs_find_dirent+0x25/0x36
[   92.994370]  [<c11049dc>] ? __sysfs_add_one+0x25/0x72
[   92.994377]  [<c1104fb5>] ? sysfs_addrm_finish+0x13/0x8f
[   92.994383]  [<c11050e6>] ? sysfs_add_one+0x10/0xc7
[   92.994390]  [<c1105506>] ? sysfs_do_create_link+0x34/0x150
[   92.994432]  [<f850348d>] ? ssb_device_probe+0x2c/0x47 [ssb]
[   92.994445]  [<c11d9954>] ? driver_probe_device+0x8c/0x110
[   92.994451]  [<c11d9a18>] ? __driver_attach+0x40/0x5b
[   92.994464]  [<c11d91b5>] ? bus_for_each_dev+0x37/0x5f
[   92.994476]  [<c11d980a>] ? driver_attach+0x11/0x13
[   92.994482]  [<c11d99d8>] ? __driver_attach+0x0/0x5b
[   92.994488]  [<c11d9530>] ? bus_add_driver+0x87/0x1bb
[   92.994495]  [<c1148c2a>] ? kset_find_obj_hinted+0x12/0x7d
[   92.994512]  [<f8393000>] ? b43_init+0x0/0x62 [b43]
[   92.994518]  [<c11d9c34>] ? driver_register+0x7a/0xd9
[   92.994534]  [<f8393000>] ? b43_init+0x0/0x62 [b43]
[   92.994549]  [<f8393026>] ? b43_init+0x26/0x62 [b43]
[   92.994556]  [<c1003069>] ? do_one_initcall+0x68/0x10f
[   92.994565]  [<c105f0d3>] ? sys_init_module+0xca5/0xe36
[   92.994608]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28
[   92.994627] BUG: unable to handle kernel paging request at 44b3442d
[   92.994632] IP: [<f90b13df>] hwrng_register+0x5f/0x14d [rng_core]
[   92.994642] *pdpt = 0000000033c0e001 *pde = 0000000000000000 
[   92.994648] Oops: 0000 [#1] SMP 
[   92.994652] last sysfs file: /sys/devices/pci0000:00/0000:00:03.0/0000:02:00.0/ssb0:0/leds/b43-phy0::radio/uevent
[   92.994658] Modules linked in: arc4 ecb b43(+) mac80211 cfg80211 uinput sco bnep rfcomm l2cap crc16 via drm 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 rng_core msr cpuid snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event joydev uvcvideo snd_seq btusb videodev snd_timer bluetooth tpm_tis tpm snd_seq_device v4l1_compat ideapad_laptop tpm_bios battery ac i2c_viapro snd rfkill power_supply soundcore snd_page_alloc processor psmouse evdev video i2c_core serio_raw pcspkr shpchp wmi output button 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 uhci_hcd pata_via ehci_hcd libata ssb tg3 usbcore scsi_mod via_sdmmc pcmcia mmc_core pcmcia_core libphy thermal thermal_sys nls_base [last unloaded: scsi_wait_scan]
[   92.994792] 
[   92.994798] Pid: 2622, comm: modprobe Not tainted 2.6.37-rc7-self #4 MoutCook/20021,2959
[   92.994803] EIP: 0060:[<f90b13df>] EFLAGS: 00010206 CPU: 0
[   92.994810] EIP is at hwrng_register+0x5f/0x14d [rng_core]
[   92.994815] EAX: 00000001 EBX: f7143010 ECX: f90b1589 EDX: f7143035
[   92.994819] ESI: 44b34411 EDI: f7142fc0 EBP: 00000000 ESP: f3c17e04
[   92.994824]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[   92.994829] Process modprobe (pid: 2622, ti=f3c16000 task=f3cba080 task.ti=f3c16000)
[   92.994833] Stack:
[   92.994836]  f7143035 f3caec00 f84b4b23 f7143035 0000001f f84cae30 f84ca9f0 f3ced0d8
[   92.994844]  2206017f f6d31c64 6161d6ee f4fa9f01 f3ced0d0 c11047aa f3d21210 f3c17e05
[   92.994853]  f3d21210 c11049dc c1104fb5 f4fa9e00 c11050e6 00000000 0000461c f6d31c00
[   92.994862] Call Trace:
[   92.994879]  [<f84b4b23>] ? b43_probe+0x9e5/0xa85 [b43]
[   92.994886]  [<c11047aa>] ? sysfs_find_dirent+0x25/0x36
[   92.994892]  [<c11049dc>] ? __sysfs_add_one+0x25/0x72
[   92.994898]  [<c1104fb5>] ? sysfs_addrm_finish+0x13/0x8f
[   92.994904]  [<c11050e6>] ? sysfs_add_one+0x10/0xc7
[   92.994910]  [<c1105506>] ? sysfs_do_create_link+0x34/0x150
[   92.994929]  [<f850348d>] ? ssb_device_probe+0x2c/0x47 [ssb]
[   92.994936]  [<c11d9954>] ? driver_probe_device+0x8c/0x110
[   92.994942]  [<c11d9a18>] ? __driver_attach+0x40/0x5b
[   92.994954]  [<c11d91b5>] ? bus_for_each_dev+0x37/0x5f
[   92.994967]  [<c11d980a>] ? driver_attach+0x11/0x13
[   92.994972]  [<c11d99d8>] ? __driver_attach+0x0/0x5b
[   92.994978]  [<c11d9530>] ? bus_add_driver+0x87/0x1bb
[   92.994984]  [<c1148c2a>] ? kset_find_obj_hinted+0x12/0x7d
[   92.995000]  [<f8393000>] ? b43_init+0x0/0x62 [b43]
[   92.995005]  [<c11d9c34>] ? driver_register+0x7a/0xd9
[   92.995021]  [<f8393000>] ? b43_init+0x0/0x62 [b43]
[   92.995036]  [<f8393026>] ? b43_init+0x26/0x62 [b43]
[   92.995042]  [<c1003069>] ? do_one_initcall+0x68/0x10f
[   92.995048]  [<c105f0d3>] ? sys_init_module+0xca5/0xe36
[   92.995086]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28
[   92.995090] Code: 1e c8 8b 35 1c 16 0b f9 59 83 ee 1c eb 1d 8b 13 8b 06 e8 84 d6 09 c8 85 c0 75 0a be ef ff ff ff e9 d3 00 00 00 8b 76 1c 83 ee 1c <8b> 46 1c 0f 18 00 90 81 fe 00 16 0b f9 75 d4 83 3d 2c 18 0b f9 
[   92.995132] EIP: [<f90b13df>] hwrng_register+0x5f/0x14d [rng_core] SS:ESP 0068:f3c17e04
[   92.995143] CR2: 0000000044b3442d
[   92.995148] ---[ end trace 66162330d52e4fa4 ]---
[   93.444122] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
[   98.960305] b43-pci-bridge 0000:02:00.0: PCI: Disallowing DAC for device
[   98.960316] b43-phy0: DMA mask fallback from 64-bit to 32-bit
[   98.990133] ADDRCONF(NETDEV_UP): wlan0: link is not ready

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Larry Finger]

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]
[   30.313715] EAX: 00000001 EBX: f4f13010 ECX: f8f4e589 EDX: f4f13035
[   30.313725] ESI: 6087064b EDI: 00000000 EBP: 00000036 ESP: f4fe7b54
[   30.313735]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[   30.313745] Process NetworkManager (pid: 1742, ti=f4fe6000 task=f6d2e8a0
task.ti=f4fe6000)
[   30.313753] Stack:
[   30.313757]  f4f12fc0 f4f13035 f8fab870 f4f13035 0000001f f8fc10bb f8fc09f0
f6dcce20
[   30.313775]  0000000f f6dcac00 f6dcac00 f6f27400 f4f122c0 f4f10240 f4f12fc8
f8fabd67
[   30.313793]  f8c273da f4f122c0 f6ec0400 f8e9ee48 f6ec0000 f8e8e889 f8e8de7a
00000000
[   30.313810] Call Trace:
[   30.313835]  [<f8fab870>] ? b43_wireless_core_init+0xd0c/0xdd6 [b43]
[   30.313863]  [<f8fabd67>] ? b43_op_start+0xf8/0x142 [b43]
[   30.313889]  [<f8c273da>] ? cfg80211_netdev_notifier_call+0x342/0x355 [cfg80211]
[   30.313926]  [<f8e8e889>] ? ieee80211_do_open+0xed/0x45f [mac80211]
[   30.313958]  [<f8e8de7a>] ? ieee80211_check_concurrent_iface+0x1c/0x135
[mac80211]
[   30.313975]  [<c1203247>] ? __dev_open+0x7d/0xa7
[   30.313986]  [<c1201c10>] ? __dev_change_flags+0x9a/0x10d
[   30.313998]  [<c120319f>] ? dev_change_flags+0x10/0x3b
[   30.314011]  [<c120d207>] ? do_setlink+0x23e/0x532
[   30.314026]  [<c129ced6>] ? schedule+0x579/0x5b6
[   30.314037]  [<c120d5cb>] ? rtnl_setlink+0xd0/0xe1
[   30.314052]  [<c114f000>] ? clear_user+0x2b/0x43
[   30.314063]  [<c120d4fb>] ? rtnl_setlink+0x0/0xe1
[   30.314074]  [<c120cd32>] ? rtnetlink_rcv_msg+0x186/0x19c
[   30.314086]  [<c120cbac>] ? rtnetlink_rcv_msg+0x0/0x19c
[   30.314098]  [<c121bda8>] ? netlink_rcv_skb+0x2d/0x72
[   30.314109]  [<c120cba6>] ? rtnetlink_rcv+0x18/0x1e
[   30.314120]  [<c121bbfc>] ? netlink_unicast+0xba/0x10e
[   30.314132]  [<c121c700>] ? netlink_sendmsg+0x23d/0x256
[   30.314145]  [<c11f53a6>] ? __sock_sendmsg+0x48/0x4e
[   30.314155]  [<c11f560f>] ? sock_sendmsg+0x78/0x8f
[   30.314167]  [<c11f560f>] ? sock_sendmsg+0x78/0x8f
[   30.314179]  [<c10cf5dd>] ? d_kill+0x38/0x3d
[   30.314192]  [<c11fd48c>] ? verify_iovec+0x3d/0x79
[   30.314203]  [<c11f5e0d>] ? sys_sendmsg+0x15f/0x1c1
[   30.314214]  [<c11f5a44>] ? sockfd_lookup_light+0x13/0x3f
[   30.314225]  [<c11f60a5>] ? sys_sendto+0xfd/0x121
[   30.314237]  [<c10079ee>] ? __switch_to+0x6f/0xe2
[   30.314250]  [<c129ced6>] ? schedule+0x579/0x5b6
[   30.314261]  [<c11f5ca3>] ? sys_recvmsg+0x3c/0x47
[   30.314272]  [<c11f707d>] ? sys_socketcall+0x17f/0x1cb
[   30.314284]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28
[   30.314292] Code: 34 c8 8b 35 1c e6 f4 f8 59 83 ee 1c eb 1d 8b 13 8b 06 e8 84
06 20 c8 85 c0 75 0a be ef ff ff ff e9 d3 00 00 00 8b 76 1c 83 ee 1c <8b> 46 1c
0f 18 00 90 81 fe 00 e6 f4 f8 75 d4 83 3d 2c e8 f4 f8
[   30.314376] EIP: [<f8f4e3df>] hwrng_register+0x5f/0x14d [rng_core] SS:ESP
0068:f4fe7b54
[   30.314395] CR2: 0000000060870667
[   30.314404] ---[ end trace f498f4a4e1f00415 ]---

Mario's box with this fault has two RNG devices - b43 and the one provided by
via-rng. Experimentation has shown that if b43 is registered first, then there
is no problem; however if via-rng is first, then the above BUG is triggered when
b43 registers its hardware rng. This problem is a regression in that one of the
changes in 2.6.37 has b43 registering its rng later in the startup sequence.

Are you the correct people to contact? If not, who is maintaining via-rng? I did
not find any entries in MAINTAINERS.

Do you see any problems in the code in drivers/net/wireless/b43/main.c or
drivers/char/hw_random/via-rng.c. As the latter seems to make b43 fail, I am
suspecting via-rng, but I have no proof.

Thanks,

Larry



On 12/30/2010 02:45 PM, Mario 'BitKoenig' Holbe wrote:
> On Thu, Dec 30, 2010 at 12:37:21PM -0600, Larry Finger wrote:
>> 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.
> 
> 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

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1.1: Type: text/plain, Size: 2828 bytes --]

On Thu, Dec 30, 2010 at 04:49:05PM -0600, Larry Finger wrote:
> 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]
> 
> Mario's box with this fault has two RNG devices - b43 and the one provided by
> via-rng. Experimentation has shown that if b43 is registered first, then there
> is no problem; however if via-rng is first, then the above BUG is triggered when
> b43 registers its hardware rng. This problem is a regression in that one of the
> changes in 2.6.37 has b43 registering its rng later in the startup sequence.
...
> Do you see any problems in the code in drivers/net/wireless/b43/main.c or
> drivers/char/hw_random/via-rng.c. As the latter seems to make b43 fail, I am
> suspecting via-rng, but I have no proof.

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

[-- Attachment #1.2: 2.6.37-rc7+via-rng2.dmesg --]
[-- Type: text/plain, Size: 4008 bytes --]

[   11.746521] VIA RNG detected
[   11.746526] Calling hwrng_register
[   11.746533] Pid: 770, comm: modprobe Not tainted 2.6.37-rc7-self #5
[   11.746536] Call Trace:
[   11.746546]  [<f90ed3ac>] ? hwrng_register+0x2c/0x14d [rng_core]
[   11.746554]  [<f90fa023>] ? mod_init+0x23/0x3b [via_rng]
[   11.746564]  [<c1003069>] ? do_one_initcall+0x68/0x10f
[   11.746574]  [<c105f0d3>] ? sys_init_module+0xca5/0xe36
[   11.746602]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28
...
[  106.660466] VIA RNG detected
[  106.660471] Calling hwrng_register
[  106.660478] Pid: 2673, comm: modprobe Not tainted 2.6.37-rc7-self #5
[  106.660482] Call Trace:
[  106.660500]  [<f90ed3ac>] ? hwrng_register+0x2c/0x14d [rng_core]
[  106.660510]  [<f830e023>] ? mod_init+0x23/0x3b [via_rng2]
[  106.660520]  [<c1003069>] ? do_one_initcall+0x68/0x10f
[  106.660532]  [<c105f0d3>] ? sys_init_module+0xca5/0xe36
[  106.660600]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28
[  106.660630] BUG: unable to handle kernel paging request at 7268d4f3
[  106.660640] IP: [<f90ed3df>] hwrng_register+0x5f/0x14d [rng_core]
[  106.660658] *pdpt = 0000000033c0a001 *pde = 0000000000000000 
[  106.660670] Oops: 0000 [#1] SMP 
[  106.660678] last sysfs file: /sys/module/rng_core/initstate
[  106.660687] Modules linked in: via_rng2(+) uinput via drm rfcomm sco bnep 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 rng_core msr cpuid snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss joydev snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd uvcvideo videodev v4l1_compat btusb ideapad_laptop soundcore video tpm_tis bluetooth psmouse i2c_viapro pcspkr tpm battery ac tpm_bios i2c_core evdev serio_raw power_supply snd_page_alloc output processor rfkill shpchp wmi pci_hotplug button 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 ssb uhci_hcd via_sdmmc ehci_hcd usbcore scsi_mod tg3 pcmcia mmc_core pcmcia_core libphy thermal thermal_sys nls_base [last unloaded: scsi_wait_scan]
[  106.660952] 
[  106.660963] Pid: 2673, comm: modprobe Not tainted 2.6.37-rc7-self #5 MoutCook/20021,2959
[  106.660975] EIP: 0060:[<f90ed3df>] EFLAGS: 00010216 CPU: 0
[  106.660987] EIP is at hwrng_register+0x5f/0x14d [rng_core]
[  106.660996] EAX: ffffffff EBX: f829e26c ECX: f90ed589 EDX: f829e267
[  106.661006] ESI: 7268d4d7 EDI: f3c7eac0 EBP: f830e000 ESP: f72b9f14
[  106.661015]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  106.661025] Process modprobe (pid: 2673, ti=f72b8000 task=f3ce30c0 task.ti=f72b8000)
[  106.661033] Stack:
[  106.661037]  ffffffed 00000000 f830e023 f829e226 f829e290 c1003069 00000000 f829e290
[  106.661055]  00000000 f3c7eac0 00000001 c105f0d3 00000017 f829e2d8 0000000a f829ac04
[  106.661072]  f3c7eac0 00000025 f829e3e0 f829a000 000010d4 f829a86c f829a788 f829ae7c
[  106.661090] Call Trace:
[  106.661102]  [<f830e023>] ? mod_init+0x23/0x3b [via_rng2]
[  106.661114]  [<c1003069>] ? do_one_initcall+0x68/0x10f
[  106.661126]  [<c105f0d3>] ? sys_init_module+0xca5/0xe36
[  106.661188]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28
[  106.661195] Code: 1b c8 8b 35 1c d6 0e f9 59 83 ee 1c eb 1d 8b 13 8b 06 e8 84 16 06 c8 85 c0 75 0a be ef ff ff ff e9 d3 00 00 00 8b 76 1c 83 ee 1c <8b> 46 1c 0f 18 00 90 81 fe 00 d6 0e f9 75 d4 83 3d 2c d8 0e f9 
[  106.661280] EIP: [<f90ed3df>] hwrng_register+0x5f/0x14d [rng_core] SS:ESP 0068:f72b9f14
[  106.661300] CR2: 000000007268d4f3
[  106.661309] ---[ end trace 4fa39662da4e519f ]---

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Herbert Xu]

On Thu, Dec 30, 2010 at 04:49:05PM -0600, Larry Finger wrote:
>
> Do you see any problems in the code in drivers/net/wireless/b43/main.c or
> drivers/char/hw_random/via-rng.c. As the latter seems to make b43 fail, I am
> suspecting via-rng, but I have no proof.

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

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

[Larry Finger]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

On 12/30/2010 06:37 PM, Herbert Xu wrote:
> On Thu, Dec 30, 2010 at 04:49:05PM -0600, Larry Finger wrote:
>>
>> Do you see any problems in the code in drivers/net/wireless/b43/main.c or
>> drivers/char/hw_random/via-rng.c. As the latter seems to make b43 fail, I am
>> suspecting via-rng, but I have no proof.
> 
> 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?

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;



[-- Attachment #2: hwrng_debug --]
[-- Type: text/plain, Size: 454 bytes --]

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;

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

[Michael Büsch]

On Thu, 2010-12-30 at 21:45 +0100, Mario 'BitKoenig' Holbe wrote: 
> On Thu, Dec 30, 2010 at 12:37:21PM -0600, Larry Finger wrote:
> > 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.
> 
> 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.


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.

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

[Larry Finger]

On 12/30/2010 07:57 PM, Michael Büsch wrote:
> On Thu, 2010-12-30 at 21:45 +0100, Mario 'BitKoenig' Holbe wrote: 
>> On Thu, Dec 30, 2010 at 12:37:21PM -0600, Larry Finger wrote:
>>> 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.
>>
>> 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.
> 
> 
> 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.

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

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1.1: Type: text/plain, Size: 1109 bytes --]

On Thu, Dec 30, 2010 at 06:46:31PM -0600, Larry Finger wrote:
> On 12/30/2010 06:37 PM, Herbert Xu wrote:
> > 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?
> 
> The following patch should be able to test if xstore is overwriting the list
> pointer.

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..."

[-- Attachment #1.2: 2.6.37-rc7+via-rng2.dmesg --]
[-- Type: text/plain, Size: 948 bytes --]

[   11.606134] VIA RNG detected
[   11.606139] Calling hwrng_register
[   11.606145] Pid: 752, comm: modprobe Not tainted 2.6.37-rc7-self #1
[   11.606149] Call Trace:
[   11.606159]  [<f90c33ac>] ? hwrng_register+0x2c/0x14d [rng_core]
[   11.606167]  [<f90d0023>] ? mod_init+0x23/0x3b [via_rng]
[   11.606176]  [<c1003069>] ? do_one_initcall+0x68/0x10f
[   11.606186]  [<c105f0d3>] ? sys_init_module+0xca5/0xe36
[   11.606214]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28
...
[   92.687121] VIA RNG detected
[   92.687126] Calling hwrng_register
[   92.687132] Pid: 2698, comm: modprobe Not tainted 2.6.37-rc7-self #1
[   92.687136] Call Trace:
[   92.687152]  [<f90c33ac>] ? hwrng_register+0x2c/0x14d [rng_core]
[   92.687161]  [<f8274023>] ? mod_init+0x23/0x3b [via_rng2]
[   92.687171]  [<c1003069>] ? do_one_initcall+0x68/0x10f
[   92.687181]  [<c105f0d3>] ? sys_init_module+0xca5/0xe36
[   92.687227]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28

[-- Attachment #1.3: 2.6.37-rc7+via-rng2+b43.dmesg --]
[-- Type: text/plain, Size: 3236 bytes --]

[   11.686811] VIA RNG detected
[   11.686816] Calling hwrng_register
[   11.686822] Pid: 807, comm: modprobe Not tainted 2.6.37-rc7-self #1
[   11.686826] Call Trace:
[   11.686839]  [<f8fb23ac>] ? hwrng_register+0x2c/0x14d [rng_core]
[   11.686847]  [<f923f023>] ? mod_init+0x23/0x3b [via_rng]
[   11.686856]  [<c1003069>] ? do_one_initcall+0x68/0x10f
[   11.686867]  [<c105f0d3>] ? sys_init_module+0xca5/0xe36
[   11.686897]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28
...
[   29.964239] b43-pci-bridge 0000:02:00.0: PCI: Disallowing DAC for device
[   29.964251] b43-phy0: DMA mask fallback from 64-bit to 32-bit
[   29.984626] Calling hwrng_register
[   29.984640] Pid: 1550, comm: NetworkManager Not tainted 2.6.37-rc7-self #1
[   29.984648] Call Trace:
[   29.984688]  [<f8fb23ac>] ? hwrng_register+0x2c/0x14d [rng_core]
[   29.984729]  [<f8ffe879>] ? b43_wireless_core_init+0xd12/0xddf [b43]
[   29.984759]  [<f8ffed73>] ? b43_op_start+0xf8/0x142 [b43]
[   29.984796]  [<f8d463da>] ? cfg80211_netdev_notifier_call+0x342/0x355 [cfg80211]
[   29.984853]  [<f8f1a889>] ? ieee80211_do_open+0xed/0x45f [mac80211]
[   29.984886]  [<f8f19e7a>] ? ieee80211_check_concurrent_iface+0x1c/0x135 [mac80211]
[   29.984908]  [<c1203247>] ? __dev_open+0x7d/0xa7
[   29.984922]  [<c1201c10>] ? __dev_change_flags+0x9a/0x10d
[   29.984934]  [<c120319f>] ? dev_change_flags+0x10/0x3b
[   29.984949]  [<c120d207>] ? do_setlink+0x23e/0x532
[   29.984965]  [<c120d5cb>] ? rtnl_setlink+0xd0/0xe1
[   29.984986]  [<c114f000>] ? clear_user+0x2b/0x43
[   29.984997]  [<c120d4fb>] ? rtnl_setlink+0x0/0xe1
[   29.985008]  [<c120cd32>] ? rtnetlink_rcv_msg+0x186/0x19c
[   29.985020]  [<c120cbac>] ? rtnetlink_rcv_msg+0x0/0x19c
[   29.985034]  [<c121bda8>] ? netlink_rcv_skb+0x2d/0x72
[   29.985046]  [<c120cba6>] ? rtnetlink_rcv+0x18/0x1e
[   29.985056]  [<c121bbfc>] ? netlink_unicast+0xba/0x10e
[   29.985068]  [<c121c700>] ? netlink_sendmsg+0x23d/0x256
[   29.985082]  [<c11f53a6>] ? __sock_sendmsg+0x48/0x4e
[   29.985093]  [<c11f560f>] ? sock_sendmsg+0x78/0x8f
[   29.985105]  [<c11f560f>] ? sock_sendmsg+0x78/0x8f
[   29.985119]  [<c10cf5dd>] ? d_kill+0x38/0x3d
[   29.985137]  [<c11fd48c>] ? verify_iovec+0x3d/0x79
[   29.985147]  [<c11f5e0d>] ? sys_sendmsg+0x15f/0x1c1
[   29.985159]  [<c11f5a44>] ? sockfd_lookup_light+0x13/0x3f
[   29.985170]  [<c11f60a5>] ? sys_sendto+0xfd/0x121
[   29.985182]  [<c11f996b>] ? sk_prot_alloc+0x62/0xd6
[   29.985195]  [<c10079ee>] ? __switch_to+0x6f/0xe2
[   29.985213]  [<c129ced6>] ? schedule+0x579/0x5b6
[   29.985225]  [<c11f5ca3>] ? sys_recvmsg+0x3c/0x47
[   29.985236]  [<c11f707d>] ? sys_socketcall+0x17f/0x1cb
[   29.985249]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28
[   29.987285] ADDRCONF(NETDEV_UP): wlan0: link is not ready
...
[   99.003298] VIA RNG detected
[   99.003303] Calling hwrng_register
[   99.003309] Pid: 2797, comm: modprobe Not tainted 2.6.37-rc7-self #1
[   99.003313] Call Trace:
[   99.003332]  [<f8fb23ac>] ? hwrng_register+0x2c/0x14d [rng_core]
[   99.003341]  [<f8281023>] ? mod_init+0x23/0x3b [via_rng2]
[   99.003350]  [<c1003069>] ? do_one_initcall+0x68/0x10f
[   99.003360]  [<c105f0d3>] ? sys_init_module+0xca5/0xe36
[   99.003403]  [<c1008b1f>] ? sysenter_do_call+0x12/0x28

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Herbert Xu]

On Fri, Dec 31, 2010 at 03:25:51AM +0100, Mario 'BitKoenig' Holbe wrote:
>
> 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.

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

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1.1: Type: text/plain, Size: 324 bytes --]

On Fri, Dec 31, 2010 at 01:46:53PM +1100, Herbert Xu wrote:
> Thanks for checking.  Can you provide the output of
> 	cat /proc/cpuinfo

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

[-- Attachment #1.2: cpuinfo --]
[-- Type: text/plain, Size: 654 bytes --]

processor	: 0
vendor_id	: CentaurHauls
cpu family	: 6
model		: 15
model name	: VIA Nano processor U2250 (1.6GHz Capable)
stepping	: 3
cpu MHz		: 1600.000
cache size	: 1024 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush acpi mmx fxsr sse sse2 ss tm syscall nx lm constant_tsc up rep_good pni monitor vmx est tm2 ssse3 cx16 xtpr rng rng_en ace ace_en ace2 phe phe_en lahf_lm
bogomips	: 3192.08
clflush size	: 64
cache_alignment	: 128
address sizes	: 36 bits physical, 48 bits virtual
power management:


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Herbert Xu]

On Fri, Dec 31, 2010 at 09:51:04AM +0100, Mario 'BitKoenig' Holbe wrote:
> On Fri, Dec 31, 2010 at 01:46:53PM +1100, Herbert Xu wrote:
> > Thanks for checking.  Can you provide the output of
> > 	cat /proc/cpuinfo
> 
> attached.

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 <linux/err.h>
 #include <linux/module.h>
@@ -22,13 +23,6 @@
 #include <linux/kernel.h>
 #include <linux/scatterlist.h>
 #include <asm/i387.h>
-#include "padlock.h"
-
-#ifdef CONFIG_64BIT
-#define STACK_ALIGN 16
-#else
-#define STACK_ALIGN 4
-#endif
 
 struct padlock_sha_desc {
 	struct shash_desc fallback;
diff --git a/drivers/crypto/padlock.h b/drivers/crypto/padlock.h
deleted file mode 100644
index b728e45..0000000
--- a/drivers/crypto/padlock.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/*
- * Driver for VIA PadLock
- *
- * Copyright (c) 2004 Michal Ludvig <michal@logix.cz>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the Free
- * Software Foundation; either version 2 of the License, or (at your option) 
- * any later version.
- *
- */
-
-#ifndef _CRYPTO_PADLOCK_H
-#define _CRYPTO_PADLOCK_H
-
-#define PADLOCK_ALIGNMENT 16
-
-#define PFX	"padlock: "
-
-#define PADLOCK_CRA_PRIORITY	300
-#define PADLOCK_COMPOSITE_PRIORITY 400
-
-#endif	/* _CRYPTO_PADLOCK_H */
diff --git a/include/crypto/padlock.h b/include/crypto/padlock.h
new file mode 100644
index 0000000..d2cfa2e
--- /dev/null
+++ b/include/crypto/padlock.h
@@ -0,0 +1,29 @@
+/*
+ * Driver for VIA PadLock
+ *
+ * Copyright (c) 2004 Michal Ludvig <michal@logix.cz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option) 
+ * any later version.
+ *
+ */
+
+#ifndef _CRYPTO_PADLOCK_H
+#define _CRYPTO_PADLOCK_H
+
+#define PADLOCK_ALIGNMENT 16
+
+#define PFX	KBUILD_MODNAME ": "
+
+#define PADLOCK_CRA_PRIORITY	300
+#define PADLOCK_COMPOSITE_PRIORITY 400
+
+#ifdef CONFIG_64BIT
+#define STACK_ALIGN 16
+#else
+#define STACK_ALIGN 4
+#endif
+
+#endif	/* _CRYPTO_PADLOCK_H */

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

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

Hello Herbert,

On Tue, Jan 04, 2011 at 03:33:38PM +1100, Herbert Xu wrote:
> 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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Herbert Xu]

On Tue, Jan 04, 2011 at 01:19:57PM +0100, Mario 'BitKoenig' Holbe wrote:
>
> 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.

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

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]

On Tue, Jan 04, 2011 at 11:38:24PM +1100, Herbert Xu wrote:
> On Tue, Jan 04, 2011 at 01:19:57PM +0100, Mario 'BitKoenig' Holbe wrote:
> >
> > 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.
> 
> Hmm, can you print out what it's actually producing (e.g., by
> stracing rngd)?

# 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
#                                                                                                                          
> Can you also double-check that this doesn't happen with Larry's
> patch?

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Herbert Xu]

On Tue, Jan 04, 2011 at 01:57:22PM +0100, Mario 'BitKoenig' Holbe wrote:
>
> # 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  |................|
> *

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
--- 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 <linux/err.h>
 #include <linux/module.h>
@@ -22,13 +23,6 @@
 #include <linux/kernel.h>
 #include <linux/scatterlist.h>
 #include <asm/i387.h>
-#include "padlock.h"
-
-#ifdef CONFIG_64BIT
-#define STACK_ALIGN 16
-#else
-#define STACK_ALIGN 4
-#endif
 
 struct padlock_sha_desc {
 	struct shash_desc fallback;
diff --git a/drivers/crypto/padlock.h b/drivers/crypto/padlock.h
deleted file mode 100644
index b728e45..0000000
--- a/drivers/crypto/padlock.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/*
- * Driver for VIA PadLock
- *
- * Copyright (c) 2004 Michal Ludvig <michal@logix.cz>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the Free
- * Software Foundation; either version 2 of the License, or (at your option) 
- * any later version.
- *
- */
-
-#ifndef _CRYPTO_PADLOCK_H
-#define _CRYPTO_PADLOCK_H
-
-#define PADLOCK_ALIGNMENT 16
-
-#define PFX	"padlock: "
-
-#define PADLOCK_CRA_PRIORITY	300
-#define PADLOCK_COMPOSITE_PRIORITY 400
-
-#endif	/* _CRYPTO_PADLOCK_H */
diff --git a/include/crypto/padlock.h b/include/crypto/padlock.h
new file mode 100644
index 0000000..d2cfa2e
--- /dev/null
+++ b/include/crypto/padlock.h
@@ -0,0 +1,29 @@
+/*
+ * Driver for VIA PadLock
+ *
+ * Copyright (c) 2004 Michal Ludvig <michal@logix.cz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option) 
+ * any later version.
+ *
+ */
+
+#ifndef _CRYPTO_PADLOCK_H
+#define _CRYPTO_PADLOCK_H
+
+#define PADLOCK_ALIGNMENT 16
+
+#define PFX	KBUILD_MODNAME ": "
+
+#define PADLOCK_CRA_PRIORITY	300
+#define PADLOCK_COMPOSITE_PRIORITY 400
+
+#ifdef CONFIG_64BIT
+#define STACK_ALIGN 16
+#else
+#define STACK_ALIGN 4
+#endif
+
+#endif	/* _CRYPTO_PADLOCK_H */

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

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

On Wed, Jan 05, 2011 at 09:42:38AM +1100, Herbert Xu wrote:
> Can you please try this patch against vanilla to print out the
> raw output of xstore?

# 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Larry Finger]

On 01/04/2011 05:06 PM, Mario 'BitKoenig' Holbe wrote:
> On Wed, Jan 05, 2011 at 09:42:38AM +1100, Herbert Xu wrote:
>> Can you please try this patch against vanilla to print out the
>> raw output of xstore?
> 
> # 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  |................|

This thread just keeps getting more and more interesting! :)

For reference, this is what I get for b43:

hexdump -n 16 -C /dev/hwrng
00000000  c7 87 ec 43 fa ac a8 c2  3b 0d a6 8f 3e 35 54 ee  |...C....;...>5T.|

Larry

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]

On Wed, Jan 05, 2011 at 12:06:44AM +0100, Mario 'BitKoenig' Holbe wrote:
> On Wed, Jan 05, 2011 at 09:42:38AM +1100, Herbert Xu wrote:
> > Can you please try this patch against vanilla to print out the
> > raw output of xstore?
> 00000000  00 ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

Btw: the same with vanilla 2.6.37-rc7 and only the printk in xstore()
from your 2nd patch:

# hexdump -n 16 -C /dev/hwrng
00000000  2b f3 16 07 e8 57 1a a9  d2 3e 7f ad 0e 78 75 7f  |+....W...>...xu.|
00000010
# 


kern.log meanwhile (lines numbered):

     1  Jan  5 00:27:09 ideapad kernel: [  122.489475] 0x25ba3b2b
     2  Jan  5 00:27:09 ideapad kernel: [  122.489486] 0xe68ae2f3
     3  Jan  5 00:27:09 ideapad kernel: [  122.489489] 0x0
     4  Jan  5 00:27:09 ideapad kernel: [  122.489502] 0x75621016
     5  Jan  5 00:27:09 ideapad kernel: [  122.489505] 0x0
     6  Jan  5 00:27:09 ideapad kernel: [  122.489518] 0x727edc07
     7  Jan  5 00:27:09 ideapad kernel: [  122.489520] 0x0
     8  Jan  5 00:27:09 ideapad kernel: [  122.489534] 0x851b82e8
     9  Jan  5 00:27:09 ideapad kernel: [  122.491241] 0xfba49c57
    10  Jan  5 00:27:09 ideapad kernel: [  122.491245] 0x0
    11  Jan  5 00:27:09 ideapad kernel: [  122.491258] 0xc63eca1a
...
  8156  Jan  5 00:27:10 ideapad kernel: [  122.782215] 0x0
  8157  Jan  5 00:27:10 ideapad kernel: [  122.782228] 0xb736d99b
  8158  Jan  5 00:27:10 ideapad kernel: [  122.782230] 0x0
  8159  Jan  5 00:27:10 ideapad kernel: [  122.782243] 0x339211fd
  8160  Jan  5 00:27:10 ideapad kernel: [  122.782246] 0x0
  8161  Jan  5 00:27:10 ideapad kernel: [  122.782258] 0x12f898d1
  8162  Jan  5 00:27:10 ideapad kernel: [  122.782261] 0x0
  8163  Jan  5 00:27:10 ideapad kernel: [  122.782273] 0xc73fcdda


Mario
-- 
The question of whether a computer can think is no more interesting than
the question of whether a submarine can swim.          -- E. W. Dijkstra

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Larry Finger]

On 01/04/2011 04:42 PM, Herbert Xu wrote:
> On Tue, Jan 04, 2011 at 01:57:22PM +0100, Mario 'BitKoenig' Holbe wrote:
>>
>> # 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  |................|
>> *
> 
> 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);

If I didn't get lost in expanding all those macros, I think the above can end up
with what is essentially a negative value for the index of buf. Shouldn't the
right-hand side of the statement be

(u32 *)PTR_ALIGN(&buf[PADLOCK_ALIGNMENT], PADLOCK_ALIGNMENT);

That resolves to an index for buf from 0 to (PADLOCK_ALIGNMENT - 1).

Larry

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

[Herbert Xu]

On Tue, Jan 04, 2011 at 06:14:16PM -0600, Larry Finger wrote:
>
> If I didn't get lost in expanding all those macros, I think the above can end up
> with what is essentially a negative value for the index of buf. Shouldn't the
> right-hand side of the statement be
> 
> (u32 *)PTR_ALIGN(&buf[PADLOCK_ALIGNMENT], PADLOCK_ALIGNMENT);
> 
> That resolves to an index for buf from 0 to (PADLOCK_ALIGNMENT - 1).

PTR_ALIGN (and ALIGN) rounds up, not down.

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

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

[Herbert Xu]

On Wed, Jan 05, 2011 at 12:06:44AM +0100, Mario 'BitKoenig' Holbe wrote:
> 
> 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

OK, so xstore really is producing crap.  Can you try this path
(also against vanilla) to print out some extra info?

diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
index 794aacb..d7ef7ac 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 "%p 0x%x 0x%x\n", addr, *addr, eax_out);
 	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
--- 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 <linux/err.h>
 #include <linux/module.h>
@@ -22,13 +23,6 @@
 #include <linux/kernel.h>
 #include <linux/scatterlist.h>
 #include <asm/i387.h>
-#include "padlock.h"
-
-#ifdef CONFIG_64BIT
-#define STACK_ALIGN 16
-#else
-#define STACK_ALIGN 4
-#endif
 
 struct padlock_sha_desc {
 	struct shash_desc fallback;
diff --git a/drivers/crypto/padlock.h b/drivers/crypto/padlock.h
deleted file mode 100644
index b728e45..0000000
--- a/drivers/crypto/padlock.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/*
- * Driver for VIA PadLock
- *
- * Copyright (c) 2004 Michal Ludvig <michal@logix.cz>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the Free
- * Software Foundation; either version 2 of the License, or (at your option) 
- * any later version.
- *
- */
-
-#ifndef _CRYPTO_PADLOCK_H
-#define _CRYPTO_PADLOCK_H
-
-#define PADLOCK_ALIGNMENT 16
-
-#define PFX	"padlock: "
-
-#define PADLOCK_CRA_PRIORITY	300
-#define PADLOCK_COMPOSITE_PRIORITY 400
-
-#endif	/* _CRYPTO_PADLOCK_H */
diff --git a/include/crypto/padlock.h b/include/crypto/padlock.h
new file mode 100644
index 0000000..d2cfa2e
--- /dev/null
+++ b/include/crypto/padlock.h
@@ -0,0 +1,29 @@
+/*
+ * Driver for VIA PadLock
+ *
+ * Copyright (c) 2004 Michal Ludvig <michal@logix.cz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option) 
+ * any later version.
+ *
+ */
+
+#ifndef _CRYPTO_PADLOCK_H
+#define _CRYPTO_PADLOCK_H
+
+#define PADLOCK_ALIGNMENT 16
+
+#define PFX	KBUILD_MODNAME ": "
+
+#define PADLOCK_CRA_PRIORITY	300
+#define PADLOCK_COMPOSITE_PRIORITY 400
+
+#ifdef CONFIG_64BIT
+#define STACK_ALIGN 16
+#else
+#define STACK_ALIGN 4
+#endif
+
+#endif	/* _CRYPTO_PADLOCK_H */

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

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

[Larry Finger]

On 01/04/2011 06:19 PM, Herbert Xu wrote:
> 
> PTR_ALIGN (and ALIGN) rounds up, not down.

I see where I got lost in the macro expansions.

I'm still trying to understand the need for the __attribute__ on the definition
for buf.

Larry

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1: Type: text/plain, Size: 2943 bytes --]

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?
> 
>  	irq_ts_restore(ts_state);
> +	printk(KERN_DEBUG "%p 0x%x 0x%x\n", addr, *addr, eax_out);
>  	return eax_out;

# dd if=/dev/hwrng bs=16 count=1 | hexdump -C
1+0 records in
1+0 records out
16 bytes (16 B) copied, 0,000288649 s, 55,4 kB/s
00000000  00 ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000010
#                                                                                   

Jan  5 02:25:00 ideapad kernel: [  112.073759] f3cc3f38 0x0 0x8
Jan  5 02:25:00 ideapad kernel: [  112.073770] f3cc3f38 0xffffffff 0x8
Jan  5 02:25:00 ideapad kernel: [  112.073774] f3cc3f30 0x0 0x0
Jan  5 02:25:00 ideapad kernel: [  112.073788] f3cc3f38 0xffffffff 0x8
Jan  5 02:25:00 ideapad kernel: [  112.073791] f3cc3f30 0x0 0x0
Jan  5 02:25:00 ideapad kernel: [  112.073805] f3cc3f38 0xffffffff 0x8
Jan  5 02:25:00 ideapad kernel: [  112.073808] f3cc3f30 0x0 0x0
Jan  5 02:25:00 ideapad kernel: [  112.073821] f3cc3f38 0xffffffff 0x8
Jan  5 02:25:00 ideapad kernel: [  112.073825] f3cc3f30 0x0 0x0
Jan  5 02:25:00 ideapad kernel: [  112.073838] f3cc3f38 0xffffffff 0x8
Jan  5 02:25:00 ideapad kernel: [  112.073841] f3cc3f30 0x0 0x0
Jan  5 02:25:00 ideapad kernel: [  112.073855] f3cc3f38 0xffffffff 0x8
Jan  5 02:25:00 ideapad kernel: [  112.073858] f3cc3f30 0x0 0x0
Jan  5 02:25:00 ideapad kernel: [  112.073872] f3cc3f38 0xffffffff 0x8
Jan  5 02:25:00 ideapad kernel: [  112.073875] f3cc3f30 0x0 0x0
Jan  5 02:25:00 ideapad kernel: [  112.073888] f3cc3f38 0xffffffff 0x8
Jan  5 02:25:00 ideapad kernel: [  112.073892] f3cc3f30 0x0 0x0
Jan  5 02:25:00 ideapad kernel: [  112.073905] f3cc3f38 0xffffffff 0x8
Jan  5 02:25:00 ideapad kernel: [  112.073908] f3cc3f30 0x0 0x0
Jan  5 02:25:00 ideapad kernel: [  112.073922] f3cc3f38 0xffffffff 0x8
Jan  5 02:25:00 ideapad kernel: [  112.073925] f3cc3f30 0x0 0x0
Jan  5 02:25:00 ideapad kernel: [  112.073938] f3cc3f38 0xffffffff 0x8
Jan  5 02:25:00 ideapad kernel: [  112.073942] f3cc3f30 0x0 0x0
Jan  5 02:25:00 ideapad kernel: [  112.073955] f3cc3f38 0xffffffff 0x8
Jan  5 02:25:00 ideapad kernel: [  112.073959] f3cc3f30 0x0 0x0
Jan  5 02:25:00 ideapad kernel: [  112.073972] f3cc3f38 0xffffffff 0x8
Jan  5 02:25:00 ideapad kernel: [  112.073975] f3cc3f30 0x0 0x0
Jan  5 02:25:00 ideapad kernel: [  112.073989] f3cc3f38 0xffffffff 0x8
Jan  5 02:25:00 ideapad kernel: [  112.073992] f3cc3f30 0x0 0x0
Jan  5 02:25:00 ideapad kernel: [  112.074005] f3cc3f38 0xffffffff 0x8


Mario
-- 
Oh Du mein Koenig ... Eine Netzgroesse schrieb mal sinngemaess:
Du musst es so lesen wie ich es meine, nicht so wie ich es schreibe.
Ich meine es natuerlich so, wie Du es schreibst 8--)
                              -- O.G. Schwenk in de.comm.chatsystems

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Herbert Xu]

On Wed, Jan 05, 2011 at 04:52:22AM +0100, Mario 'BitKoenig' Holbe wrote:
>
> 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.

Interesting.  So your compiler was producing incorrect output.
What version of gcc were you using?

Please attach the assembly output of the function in question.

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

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1.1: Type: text/plain, Size: 2952 bytes --]

On Wed, Jan 05, 2011 at 04:47:35PM +1100, Herbert Xu wrote:
> On Wed, Jan 05, 2011 at 04:52:22AM +0100, Mario 'BitKoenig' Holbe wrote:
> > 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.
> Interesting.  So your compiler was producing incorrect output.

Why incorrect? How should the compiler know that EDI gets modified?
It's listed as XSTORE input only.

> What version of gcc were you using?

gcc version 4.4.5 (Debian 4.4.5-10) 

> Please attach the assembly output of the function in question.

attached. I hope I got the gcc call right. However, I prefer the objdump
output anyways, so this one is attached as well.

As you can see (from both, maybe less from the one, more from the
other), it is as I supposed it to be: the optimizer uses EDI to store
via_rng_datum - reasonable, since EDI is a required input for the asm()
directive anyways. And since it doesn't know EDI gets modified, it just
continues using it as via_rng_datum afterwards.

Btw: this is also the reason why it did work before: before, &rng->priv
was never used again in a close-enough (and static enough) context, so
it didn't matter whether EDI (which surely was used as &rng->priv) was
clobbered or not.

The IMHO best solution would be to tell the compiler that EDI gets
clobbered: attached via-rng1-preferred.patch to apply on top of your
first patch. However, as I already said, the compiler starts whining
with either of both inputs on the clobber-list (don't really know why it
cries for edx, but well...).

The overkill solution is to preserve EDI manually: attached
via-rng1-overkill.patch to apply on top of your first patch.
And... yes, this works, really :)

As I already said in my mail before: IMHO, for completeness, EDX should
be preserved as well: the PadLock Quick Reference states the upper 30
bits of EDX will be zeroed by XSTORE, the VIA PadLock Programming Guide
states they may be zeroed.
This does currently not really matter, since a) VIA_RNG_CHUNK_1 (0x03)
is quite zero in the upper 30 bits, and b) the XSTORE quality factor is
only defined with 2 bits.
Though it's hard to believe this could ever change, I could imagine
future code that, for example, tries to balance quality/speed, and
chooses different values for EDX (and overloads the upper 30 bits for
some additional internal information) and after xstore() behaves
different based on the value chosen before. Then, it would matter.


Mario
-- 
It is practically impossible to teach good programming style to students
that have had prior exposure to BASIC: as potential programmers they are
mentally mutilated beyond hope of regeneration.  -- Dijkstra

[-- Attachment #1.2: via-rng.S.bz2 --]
[-- Type: application/octet-stream, Size: 33188 bytes --]

[-- Attachment #1.3: via-rng.o.objdump.bz2 --]
[-- Type: application/octet-stream, Size: 4078 bytes --]

[-- Attachment #1.4: via-rng1-preferred.patch --]
[-- Type: text/x-diff, Size: 483 bytes --]

--- linux-source-2.6.37-rc7/drivers/char/hw_random/via-rng.c.hxu1	2011-01-05 11:32:12.508274625 +0100
+++ linux-source-2.6.37-rc7/drivers/char/hw_random/via-rng.c	2011-01-05 12:57:19.712085325 +0100
@@ -82,7 +82,8 @@ static inline u32 xstore(u32 *addr, u32
 
 	asm(".byte 0x0F,0xA7,0xC0 /* xstore %%edi (addr=%0) */"
 		:"=m"(*addr), "=a"(eax_out)
-		:"D"(addr), "d"(edx_in));
+		:"D"(addr), "d"(edx_in)
+		:"edi", "edx");
 
 	irq_ts_restore(ts_state);
 	return eax_out;

[-- Attachment #1.5: via-rng1-overkill.patch --]
[-- Type: text/x-diff, Size: 525 bytes --]

--- linux-source-2.6.37-rc7/drivers/char/hw_random/via-rng.c.hxu1	2011-01-05 11:32:12.508274625 +0100
+++ linux-source-2.6.37-rc7/drivers/char/hw_random/via-rng.c	2011-01-05 12:45:43.459208713 +0100
@@ -80,7 +80,9 @@ static inline u32 xstore(u32 *addr, u32
 
 	ts_state = irq_ts_save();
 
-	asm(".byte 0x0F,0xA7,0xC0 /* xstore %%edi (addr=%0) */"
+	asm("pushl %%edi\n"
+	    ".byte 0x0F,0xA7,0xC0 /* xstore %%edi (addr=%0) */\n"
+	    "popl %%edi\n"
 		:"=m"(*addr), "=a"(eax_out)
 		:"D"(addr), "d"(edx_in));
 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Herbert Xu]

On Wed, Jan 05, 2011 at 02:16:22PM +0100, Mario 'BitKoenig' Holbe wrote:
>
> attached. I hope I got the gcc call right. However, I prefer the objdump
> output anyways, so this one is attached as well.

I see what you mean now.

Please let me know if this patch (still against vanilla) helps.

diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
index 794aacb..6788bbc 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 {
@@ -81,8 +81,13 @@ static inline u32 xstore(u32 *addr, u32 edx_in)
 	ts_state = irq_ts_save();
 
 	asm(".byte 0x0F,0xA7,0xC0 /* xstore %%edi (addr=%0) */"
-		:"=m"(*addr), "=a"(eax_out)
-		:"D"(addr), "d"(edx_in));
+		: "=m" (*addr), "=a" (eax_out), "+D" (addr)
+		: "d" (edx_in)
+#ifdef CONFIG_64BIT
+		: "%rcx");
+#else
+		: "%ecx");
+#endif
 
 	irq_ts_restore(ts_state);
 	return eax_out;
@@ -90,8 +95,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 +122,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 <linux/err.h>
 #include <linux/module.h>
@@ -22,13 +23,6 @@
 #include <linux/kernel.h>
 #include <linux/scatterlist.h>
 #include <asm/i387.h>
-#include "padlock.h"
-
-#ifdef CONFIG_64BIT
-#define STACK_ALIGN 16
-#else
-#define STACK_ALIGN 4
-#endif
 
 struct padlock_sha_desc {
 	struct shash_desc fallback;
diff --git a/drivers/crypto/padlock.h b/drivers/crypto/padlock.h
deleted file mode 100644
index b728e45..0000000
--- a/drivers/crypto/padlock.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/*
- * Driver for VIA PadLock
- *
- * Copyright (c) 2004 Michal Ludvig <michal@logix.cz>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the Free
- * Software Foundation; either version 2 of the License, or (at your option) 
- * any later version.
- *
- */
-
-#ifndef _CRYPTO_PADLOCK_H
-#define _CRYPTO_PADLOCK_H
-
-#define PADLOCK_ALIGNMENT 16
-
-#define PFX	"padlock: "
-
-#define PADLOCK_CRA_PRIORITY	300
-#define PADLOCK_COMPOSITE_PRIORITY 400
-
-#endif	/* _CRYPTO_PADLOCK_H */
diff --git a/include/crypto/padlock.h b/include/crypto/padlock.h
new file mode 100644
index 0000000..d2cfa2e
--- /dev/null
+++ b/include/crypto/padlock.h
@@ -0,0 +1,29 @@
+/*
+ * Driver for VIA PadLock
+ *
+ * Copyright (c) 2004 Michal Ludvig <michal@logix.cz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option) 
+ * any later version.
+ *
+ */
+
+#ifndef _CRYPTO_PADLOCK_H
+#define _CRYPTO_PADLOCK_H
+
+#define PADLOCK_ALIGNMENT 16
+
+#define PFX	KBUILD_MODNAME ": "
+
+#define PADLOCK_CRA_PRIORITY	300
+#define PADLOCK_COMPOSITE_PRIORITY 400
+
+#ifdef CONFIG_64BIT
+#define STACK_ALIGN 16
+#else
+#define STACK_ALIGN 4
+#endif
+
+#endif	/* _CRYPTO_PADLOCK_H */

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

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1.1: Type: text/plain, Size: 1278 bytes --]

Hello Herbert,

On Thu, Jan 06, 2011 at 05:12:41PM +1100, Herbert Xu wrote:
> On Wed, Jan 05, 2011 at 02:16:22PM +0100, Mario 'BitKoenig' Holbe wrote:
> > attached. I hope I got the gcc call right. However, I prefer the objdump
> > output anyways, so this one is attached as well.
> I see what you mean now.
> Please let me know if this patch (still against vanilla) helps.

The patch helps. No crashes, meaningful random data - perfect.
I still have 2 small annotations...

1. Having ECX on the clobber-list is not really necessary.
XSTORE doesn't touch ECX at all.
REP XSTORE would touch it, but for this ECX would be an input anyways.

2. Would you mind doing the same for EDX as you did for EDI?
This doesn't really change anything currently, but will probably help
avoiding a debug-session like ours somewhere in the future :)

A patch that does both is attached - to apply on top of your patch, if
you like. I tested this patch - it passed all my tests: no crashes,
meaningful random data.


Thanks for your help & regards
   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

[-- Attachment #1.2: via-rng4-edx+unclobber.patch --]
[-- Type: text/x-diff, Size: 564 bytes --]

--- linux-source-2.6.37-rc7/drivers/char/hw_random/via-rng.c.hxu4	2011-01-06 09:40:44.879334924 +0100
+++ linux-source-2.6.37-rc7/drivers/char/hw_random/via-rng.c	2011-01-06 13:07:25.031181409 +0100
@@ -81,13 +81,7 @@
 	ts_state = irq_ts_save();
 
 	asm(".byte 0x0F,0xA7,0xC0 /* xstore %%edi (addr=%0) */"
-		: "=m" (*addr), "=a" (eax_out), "+D" (addr)
-		: "d" (edx_in)
-#ifdef CONFIG_64BIT
-		: "%rcx");
-#else
-		: "%ecx");
-#endif
+		: "=m" (*addr), "=a" (eax_out), "+D" (addr), "+d" (edx_in));
 
 	irq_ts_restore(ts_state);
 	return eax_out;

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Herbert Xu]

On Thu, Jan 06, 2011 at 02:15:16PM +0100, Mario 'BitKoenig' Holbe wrote:
>
> The patch helps. No crashes, meaningful random data - perfect.
> I still have 2 small annotations...

Thanks for testing!

> 1. Having ECX on the clobber-list is not really necessary.
> XSTORE doesn't touch ECX at all.
> REP XSTORE would touch it, but for this ECX would be an input anyways.

The documentation wasn't clear whether ECX would be updated without
the REP prefix so I included it to be on the safe side.  Unfortunately
my only VIA machine is on another continent at the moment so I can't
test it myself.  Can you verify that ECX isn't changed without the
REP prefix?

> 2. Would you mind doing the same for EDX as you did for EDI?
> This doesn't really change anything currently, but will probably help
> avoiding a debug-session like ours somewhere in the future :)

According to my documentation EDX isn't be modified (nor would it
make sense as it would break REP XSTORE).  Are you seeing anything
different?

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

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

[Larry Finger]

On 01/06/2011 07:35 AM, Herbert Xu wrote:
> On Thu, Jan 06, 2011 at 02:15:16PM +0100, Mario 'BitKoenig' Holbe wrote:
>>
>> The patch helps. No crashes, meaningful random data - perfect.
>> I still have 2 small annotations...
> 
> Thanks for testing!
> 
>> 1. Having ECX on the clobber-list is not really necessary.
>> XSTORE doesn't touch ECX at all.
>> REP XSTORE would touch it, but for this ECX would be an input anyways.
> 
> The documentation wasn't clear whether ECX would be updated without
> the REP prefix so I included it to be on the safe side.  Unfortunately
> my only VIA machine is on another continent at the moment so I can't
> test it myself.  Can you verify that ECX isn't changed without the
> REP prefix?
> 
>> 2. Would you mind doing the same for EDX as you did for EDI?
>> This doesn't really change anything currently, but will probably help
>> avoiding a debug-session like ours somewhere in the future :)
> 
> According to my documentation EDX isn't be modified (nor would it
> make sense as it would break REP XSTORE).  Are you seeing anything
> different?

As an interested observer, I think this routine needs some really detailed comments.

Larry

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

[Mario 'BitKoenig' Holbe]

[-- Attachment #1.1: Type: text/plain, Size: 1887 bytes --]

On Fri, Jan 07, 2011 at 12:35:41AM +1100, Herbert Xu wrote:
> On Thu, Jan 06, 2011 at 02:15:16PM +0100, Mario 'BitKoenig' Holbe wrote:
> > 1. Having ECX on the clobber-list is not really necessary.
> > XSTORE doesn't touch ECX at all.
> > REP XSTORE would touch it, but for this ECX would be an input anyways.
> 
> The documentation wasn't clear whether ECX would be updated without
> the REP prefix so I included it to be on the safe side.  Unfortunately
> my only VIA machine is on another continent at the moment so I can't
> test it myself.  Can you verify that ECX isn't changed without the
> REP prefix?

session-log (including small test case) attached: ECX is not changed.

> > 2. Would you mind doing the same for EDX as you did for EDI?
> According to my documentation EDX isn't be modified (nor would it
> make sense as it would break REP XSTORE).  Are you seeing anything
> different?

http://linux.via.com.tw/support/beginDownload.action?eleid=181&fid=261
VIA PadLock Programming Guide, v1.66, 4th August 2005
2.1 XSTORE Instructions (page 9)
RNG Quality Factor: EDX
[...] Only the lower two bits of EDX are meaningful; the upper 30 bits
are ignored by the instruction and may be set to zero.
                                   ^^^^^^^^^^^^^^^^^^

http://hackipedia.org/Hardware/CPU/x86/chip,%20VIA/nano/Padlock,%20quick%20reference%20v0.95%20(July%2025th,%202008).pdf
PadLock Quick Reference, v0.95, 25th July 2008
RANDOM NUMBER GENERATION (page 3)
Register Usage: Output
EDX Bits 0:1 are unchanged, all higher order bits are zero.
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

See the attached session-log as well: those EDX bits are indeed zeroed.


Btw: I believe both documents are quite clear regarding ECX for XSTORE.


Mario
-- 
User sind wie ideale Gase - sie verteilen sich gleichmaessig ueber alle Platten

[-- Attachment #1.2: via-rng-test.out --]
[-- Type: text/plain, Size: 1042 bytes --]

holbe@ideapad ~ % cat via-rng-test.c
#include <stdio.h>
#include <string.h>

static inline unsigned long xstore(unsigned long *addr, unsigned long edx)
{
	unsigned long eax_out;
	unsigned long ecx = 0xaa55aa55;
	int ts_state;

	printf("ecx: %08lx\tedx: %08lx\tedi: %p\n", ecx, edx, addr);

	asm(".byte 0x0F,0xA7,0xC0 /* xstore %%edi (addr=%0) */"
		: "=m" (*addr), "=a" (eax_out), "+D" (addr), "+d" (edx), "+c" (ecx));

	printf("ecx: %08lx\tedx: %08lx\tedi: %p\n", ecx, edx, addr);

	return eax_out;
}

int main(void) {
	unsigned long addr[8];

	memset(addr, 0, sizeof(addr));

	printf("%p: %08lx\n", addr, *(unsigned long *)addr);
	xstore(addr, 0xffffff03); /* 8 rand bits, 32 stored bits */
	printf("%p: %08lx\n", addr, *(unsigned long *)addr);

	return 0;
}
holbe@ideapad ~ % gcc -o via-rng-test via-rng-test.c
holbe@ideapad ~ % ./via-rng-test
0xbff09d40: 00000000
ecx: aa55aa55   edx: ffffff03   edi: 0xbff09d40
ecx: aa55aa55   edx: 00000003   edi: 0xbff09d48
0xbff09d40: 339d4525
holbe@ideapad ~ % 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Herbert Xu]

On Thu, Jan 06, 2011 at 03:42:55PM +0100, Mario 'BitKoenig' Holbe wrote:
>
> holbe@ideapad ~ % gcc -o via-rng-test via-rng-test.c
> holbe@ideapad ~ % ./via-rng-test
> 0xbff09d40: 00000000
> ecx: aa55aa55   edx: ffffff03   edi: 0xbff09d40
> ecx: aa55aa55   edx: 00000003   edi: 0xbff09d48
> 0xbff09d40: 339d4525
> holbe@ideapad ~ % 

Thanks, I've applied this patch:

commit 0735ac1f2551d9f9d356126aaf3b1110150918e6
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Fri Jan 7 14:48:57 2011 +1100

    hwrng: via_rng - Fix asm constraints
    
    The inline asm to invoke xstore did not specify the constraints
    correctly.  In particular, dx/di should have been marked as output
    registers as well as input as they're modified by xstore.
    
    Thanks to Mario Holbe for creating this patch and testing it.
    
    Tested-by: Mario 'BitKoenig' Holbe <Mario.Holbe@TU-Ilmenau.DE>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
index 794aacb..7f86666 100644
--- a/drivers/char/hw_random/via-rng.c
+++ b/drivers/char/hw_random/via-rng.c
@@ -81,8 +81,7 @@ static inline u32 xstore(u32 *addr, u32 edx_in)
 	ts_state = irq_ts_save();
 
 	asm(".byte 0x0F,0xA7,0xC0 /* xstore %%edi (addr=%0) */"
-		:"=m"(*addr), "=a"(eax_out)
-		:"D"(addr), "d"(edx_in));
+		: "=m" (*addr), "=a" (eax_out), "+d" (edx_in), "+D" (addr));
 
 	irq_ts_restore(ts_state);
 	return eax_out;

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

crypto: padlock - Move padlock.h into include/crypto

[Herbert Xu]

On Fri, Jan 07, 2011 at 02:49:48PM +1100, Herbert Xu wrote:
>
> commit 0735ac1f2551d9f9d356126aaf3b1110150918e6
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date:   Fri Jan 7 14:48:57 2011 +1100

Here are the other patches to fix this problem:

commit 21493088733e6e09dac6f54595a1b6b8ab1e68fd
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Fri Jan 7 14:52:00 2011 +1100

    crypto: padlock - Move padlock.h into include/crypto
    
    This patch moves padlock.h from drivers/crypto into include/crypto
    so that it may be used by the via-rng driver.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

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 <linux/err.h>
 #include <linux/module.h>
@@ -22,13 +23,6 @@
 #include <linux/kernel.h>
 #include <linux/scatterlist.h>
 #include <asm/i387.h>
-#include "padlock.h"
-
-#ifdef CONFIG_64BIT
-#define STACK_ALIGN 16
-#else
-#define STACK_ALIGN 4
-#endif
 
 struct padlock_sha_desc {
 	struct shash_desc fallback;
diff --git a/drivers/crypto/padlock.h b/drivers/crypto/padlock.h
deleted file mode 100644
index b728e45..0000000
--- a/drivers/crypto/padlock.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/*
- * Driver for VIA PadLock
- *
- * Copyright (c) 2004 Michal Ludvig <michal@logix.cz>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the Free
- * Software Foundation; either version 2 of the License, or (at your option) 
- * any later version.
- *
- */
-
-#ifndef _CRYPTO_PADLOCK_H
-#define _CRYPTO_PADLOCK_H
-
-#define PADLOCK_ALIGNMENT 16
-
-#define PFX	"padlock: "
-
-#define PADLOCK_CRA_PRIORITY	300
-#define PADLOCK_COMPOSITE_PRIORITY 400
-
-#endif	/* _CRYPTO_PADLOCK_H */
diff --git a/include/crypto/padlock.h b/include/crypto/padlock.h
new file mode 100644
index 0000000..d2cfa2e
--- /dev/null
+++ b/include/crypto/padlock.h
@@ -0,0 +1,29 @@
+/*
+ * Driver for VIA PadLock
+ *
+ * Copyright (c) 2004 Michal Ludvig <michal@logix.cz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option) 
+ * any later version.
+ *
+ */
+
+#ifndef _CRYPTO_PADLOCK_H
+#define _CRYPTO_PADLOCK_H
+
+#define PADLOCK_ALIGNMENT 16
+
+#define PFX	KBUILD_MODNAME ": "
+
+#define PADLOCK_CRA_PRIORITY	300
+#define PADLOCK_COMPOSITE_PRIORITY 400
+
+#ifdef CONFIG_64BIT
+#define STACK_ALIGN 16
+#else
+#define STACK_ALIGN 4
+#endif
+
+#endif	/* _CRYPTO_PADLOCK_H */

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

hwrng: via_rng - Fix memory scribbling on some CPUs

[Herbert Xu]

commit 55db8387a5e8d07407f0b7c6b2526417a2bc6243
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Fri Jan 7 14:55:06 2011 +1100

    hwrng: via_rng - Fix memory scribbling on some CPUs
    
    It has been reported that on at least one Nano CPU the xstore
    instruction will write as many as 16 bytes of data to the output
    buffer.
    
    This causes memory corruption as we use rng->priv which is only
    4-8 bytes long.
    
    This patch fixes this by using an intermediate buffer on the stack
    with at least 16 bytes and aligned to a 16-byte boundary.
    
    The problem was observed on the following processor:
    
    processor	: 0
    vendor_id	: CentaurHauls
    cpu family	: 6
    model		: 15
    model name	: VIA Nano processor U2250 (1.6GHz Capable)
    stepping	: 3
    cpu MHz		: 1600.000
    cache size	: 1024 KB
    fdiv_bug	: no
    hlt_bug		: no
    f00f_bug	: no
    coma_bug	: no
    fpu		: yes
    fpu_exception	: yes
    cpuid level	: 10
    wp		: yes
    flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush acpi mmx fxsr sse sse2 ss tm syscall nx lm constant_tsc up rep_good pni monitor vmx est tm2 ssse3 cx16 xtpr rng rng_en ace ace_en ace2 phe phe_en lahf_lm
    bogomips	: 3192.08
    clflush size	: 64
    cache_alignment	: 128
    address sizes	: 36 bits physical, 48 bits virtual
    power management:
    
    Tested-by: Mario 'BitKoenig' Holbe <Mario.Holbe@TU-Ilmenau.DE>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
index 7f86666..d0387a8 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 {
@@ -89,8 +89,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,
@@ -114,6 +116,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;
 }

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

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

[Maciej Rutecki]

(CC added)

I created a Bugzilla entry at 
https://bugzilla.kernel.org/show_bug.cgi?id=25812
for your bug report, please add your address to the CC list in there, thanks!


On wtorek, 28 grudnia 2010 o 14:32:29 Mario 'BitKoenig' Holbe wrote:
> Hello,
> 
> on 2.6.37-rc7 the b43 driver crashes in hwrng_register(). This makes the
> system virtually unusable since it appears to block networking syscalls.
> This leads to, for example, ifconfig never return.
> This issue does also exist in 2.6.37-rc5.
> This issue does not exist in 2.6.36.2.
> 
> The hardware in question is:
> 02:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g
> LP-PHY [14e4:4315] (rev 01) on a Lenovo Ideapad S12 with VIA Nano.
> 
> dmesg excerpt:
> [    2.056847] b43-pci-bridge 0000:02:00.0: PCI INT A -> GSI 28 (level,
> low) -> IRQ 28 [    2.056864] b43-pci-bridge 0000:02:00.0: setting latency
> timer to 64 ...
> [    8.643695] b43-phy0: Broadcom 4312 WLAN found (core revision 15)
> [    9.047514] ieee80211 phy0: Selected rate control algorithm
> 'minstrel_ht' [    9.048441] Registered led device: b43-phy0::tx
> [    9.048479] Registered led device: b43-phy0::rx
> [    9.048518] Registered led device: b43-phy0::radio
> [    9.048542] Broadcom 43xx driver loaded [ Features: PMLS, Firmware-ID:
> FW13 ] ...
> [   24.312100] b43-phy0: Loading firmware version 410.2160 (2007-05-26
> 15:32:10) ...
> [   29.848400] b43-pci-bridge 0000:02:00.0: PCI: Disallowing DAC for device
> [   29.848407] b43-phy0: DMA mask fallback from 64-bit to 32-bit
> [   29.868632] BUG: unable to handle kernel paging request at 907cde0c
> [   29.868640] IP: [<f8d543cc>] hwrng_register+0x4c/0x139 [rng_core]
> [   29.868655] *pde = 00000000
> [   29.868659] Oops: 0000 [#1] SMP
> [   29.868664] last sysfs file: /sys/bus/pci/drivers/parport_pc/uevent
> [   29.868670] Modules linked in: 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 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 libphy thermal thermal_sys nls_base [last
> unloaded: scsi_wait_scan] [   29.868810]
> [   29.868816] Pid: 1781, comm: NetworkManager Not tainted 2.6.37-rc7-686
> #1 MoutCook/20021,2959 [   29.868822] EIP: 0060:[<f8d543cc>] EFLAGS:
> 00010286 CPU: 0
> [   29.868829] EIP is at hwrng_register+0x4c/0x139 [rng_core]
> [   29.868834] EAX: 00000001 EBX: f4b17010 ECX: f6e5db6c EDX: f4b17035
> [   29.868839] ESI: 907cddf0 EDI: 00000000 EBP: 00000036 ESP: f6e5db54
> [   29.868844]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [   29.868850] Process NetworkManager (pid: 1781, ti=f6e5c000 task=f6eb6080
> task.ti=f6e5c000) [   29.868854] Stack:
> [   29.868856]  f4b16fc0 f4b17035 f8e5a870 f4b17035 0000001f f8e70095
> f8e6f9ca f4b71e70 [   29.868866]  0000000f f6c95000 f6c95000 f6e97400
> f4b162c0 f4b10240 f4b16fc8 f8e5ad67 [   29.868875]  f89e43da f4b162c0
> f6cab400 f8b80e44 f6cab000 f8b70889 f8b6fe7a 00000000 [   29.868884] Call
> Trace:
> [   29.868909]  [<f8e5a870>] ? b43_wireless_core_init+0xd0c/0xdd6 [b43]
> [   29.868925]  [<f8e5ad67>] ? b43_op_start+0xf8/0x142 [b43]
> [   29.868947]  [<f89e43da>] ? cfg80211_netdev_notifier_call+0x342/0x355
> [cfg80211] [   29.868984]  [<f8b70889>] ? ieee80211_do_open+0xed/0x45f
> [mac80211] [   29.869002]  [<f8b6fe7a>] ?
> ieee80211_check_concurrent_iface+0x1c/0x135 [mac80211] [   29.869015] 
> [<c11edcba>] ? __dev_open+0x7d/0xa7
> [   29.869022]  [<c11ec683>] ? __dev_change_flags+0x9a/0x10d
> [   29.869028]  [<c11edc12>] ? dev_change_flags+0x10/0x3b
> [   29.869036]  [<c11f7c77>] ? do_setlink+0x23e/0x532
> [   29.869044]  [<c11f803b>] ? rtnl_setlink+0xd0/0xe1
> [   29.869058]  [<c1145b00>] ? __strncpy_from_user+0x1d/0x2b
> [   29.869064]  [<c11f7f6b>] ? rtnl_setlink+0x0/0xe1
> [   29.869069]  [<c11f77a2>] ? rtnetlink_rcv_msg+0x186/0x19c
> [   29.869075]  [<c11f761c>] ? rtnetlink_rcv_msg+0x0/0x19c
> [   29.869082]  [<c1206818>] ? netlink_rcv_skb+0x2d/0x72
> [   29.869088]  [<c11f7616>] ? rtnetlink_rcv+0x18/0x1e
> [   29.869093]  [<c120666c>] ? netlink_unicast+0xba/0x10e
> [   29.869099]  [<c1207170>] ? netlink_sendmsg+0x23d/0x256
> [   29.869111]  [<c11dfe26>] ? __sock_sendmsg+0x48/0x4e
> [   29.869117]  [<c11e008f>] ? sock_sendmsg+0x78/0x8f
> [   29.869123]  [<c11e008f>] ? sock_sendmsg+0x78/0x8f
> [   29.869131]  [<c10c6785>] ? d_kill+0x38/0x3d
> [   29.869141]  [<c11e7f0c>] ? verify_iovec+0x3d/0x79
> [   29.869147]  [<c11e088d>] ? sys_sendmsg+0x15f/0x1c1
> [   29.869153]  [<c11e04c4>] ? sockfd_lookup_light+0x13/0x3f
> [   29.869160]  [<c11e0b25>] ? sys_sendto+0xfd/0x121
> [   29.869166]  [<c11e43eb>] ? sk_prot_alloc+0x62/0xd6
> [   29.869174]  [<c1001e6e>] ? __switch_to+0x6f/0xe2
> [   29.869183]  [<c12860de>] ? schedule+0x579/0x5b6
> [   29.869190]  [<c11e0723>] ? sys_recvmsg+0x3c/0x47
> [   29.869196]  [<c11e1afd>] ? sys_socketcall+0x17f/0x1cb
> [   29.869202]  [<c1002f9f>] ? sysenter_do_call+0x12/0x28
> [   29.869206] Code: f8 e8 46 25 53 c8 8b 35 ec 45 d5 f8 eb 1a 8b 13 8b 06
> e8 17 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 0f 18 00 90 81 fe d0 45 d5 f8 75 d4 83 3d ec 47 d5 f8 [  
> 29.869249] EIP: [<f8d543cc>] hwrng_register+0x4c/0x139 [rng_core] SS:ESP
> 0068:f6e5db54 [   29.869259] CR2: 00000000907cde0c
> [   29.869264] ---[ end trace 6719399ed79e8cc1 ]---
> 
> 
> regards
>    Mario

-- 
Maciej Rutecki
http://www.maciek.unixy.pl

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

[Mario 'BitKoenig' Holbe]

Hello,

on 2.6.37-rc7 the b43 driver crashes in hwrng_register(). This makes the
system virtually unusable since it appears to block networking syscalls.
This leads to, for example, ifconfig never return.
This issue does also exist in 2.6.37-rc5.
This issue does not exist in 2.6.36.2.

The hardware in question is:
02:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g LP-PHY [14e4:4315] (rev 01)
on a Lenovo Ideapad S12 with VIA Nano.

dmesg excerpt:
[    2.056847] b43-pci-bridge 0000:02:00.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
[    2.056864] b43-pci-bridge 0000:02:00.0: setting latency timer to 64
...
[    8.643695] b43-phy0: Broadcom 4312 WLAN found (core revision 15)
[    9.047514] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[    9.048441] Registered led device: b43-phy0::tx
[    9.048479] Registered led device: b43-phy0::rx
[    9.048518] Registered led device: b43-phy0::radio
[    9.048542] Broadcom 43xx driver loaded [ Features: PMLS, Firmware-ID: FW13 ]
...
[   24.312100] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
...
[   29.848400] b43-pci-bridge 0000:02:00.0: PCI: Disallowing DAC for device
[   29.848407] b43-phy0: DMA mask fallback from 64-bit to 32-bit
[   29.868632] BUG: unable to handle kernel paging request at 907cde0c
[   29.868640] IP: [<f8d543cc>] hwrng_register+0x4c/0x139 [rng_core]
[   29.868655] *pde = 00000000 
[   29.868659] Oops: 0000 [#1] SMP 
[   29.868664] last sysfs file: /sys/bus/pci/drivers/parport_pc/uevent
[   29.868670] Modules linked in: 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 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 libphy thermal thermal_sys nls_base [last unloaded: scsi_wait_scan]
[   29.868810] 
[   29.868816] Pid: 1781, comm: NetworkManager Not tainted 2.6.37-rc7-686 #1 MoutCook/20021,2959
[   29.868822] EIP: 0060:[<f8d543cc>] EFLAGS: 00010286 CPU: 0
[   29.868829] EIP is at hwrng_register+0x4c/0x139 [rng_core]
[   29.868834] EAX: 00000001 EBX: f4b17010 ECX: f6e5db6c EDX: f4b17035
[   29.868839] ESI: 907cddf0 EDI: 00000000 EBP: 00000036 ESP: f6e5db54
[   29.868844]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[   29.868850] Process NetworkManager (pid: 1781, ti=f6e5c000 task=f6eb6080 task.ti=f6e5c000)
[   29.868854] Stack:
[   29.868856]  f4b16fc0 f4b17035 f8e5a870 f4b17035 0000001f f8e70095 f8e6f9ca f4b71e70
[   29.868866]  0000000f f6c95000 f6c95000 f6e97400 f4b162c0 f4b10240 f4b16fc8 f8e5ad67
[   29.868875]  f89e43da f4b162c0 f6cab400 f8b80e44 f6cab000 f8b70889 f8b6fe7a 00000000
[   29.868884] Call Trace:
[   29.868909]  [<f8e5a870>] ? b43_wireless_core_init+0xd0c/0xdd6 [b43]
[   29.868925]  [<f8e5ad67>] ? b43_op_start+0xf8/0x142 [b43]
[   29.868947]  [<f89e43da>] ? cfg80211_netdev_notifier_call+0x342/0x355 [cfg80211]
[   29.868984]  [<f8b70889>] ? ieee80211_do_open+0xed/0x45f [mac80211]
[   29.869002]  [<f8b6fe7a>] ? ieee80211_check_concurrent_iface+0x1c/0x135 [mac80211]
[   29.869015]  [<c11edcba>] ? __dev_open+0x7d/0xa7
[   29.869022]  [<c11ec683>] ? __dev_change_flags+0x9a/0x10d
[   29.869028]  [<c11edc12>] ? dev_change_flags+0x10/0x3b
[   29.869036]  [<c11f7c77>] ? do_setlink+0x23e/0x532
[   29.869044]  [<c11f803b>] ? rtnl_setlink+0xd0/0xe1
[   29.869058]  [<c1145b00>] ? __strncpy_from_user+0x1d/0x2b
[   29.869064]  [<c11f7f6b>] ? rtnl_setlink+0x0/0xe1
[   29.869069]  [<c11f77a2>] ? rtnetlink_rcv_msg+0x186/0x19c
[   29.869075]  [<c11f761c>] ? rtnetlink_rcv_msg+0x0/0x19c
[   29.869082]  [<c1206818>] ? netlink_rcv_skb+0x2d/0x72
[   29.869088]  [<c11f7616>] ? rtnetlink_rcv+0x18/0x1e
[   29.869093]  [<c120666c>] ? netlink_unicast+0xba/0x10e
[   29.869099]  [<c1207170>] ? netlink_sendmsg+0x23d/0x256
[   29.869111]  [<c11dfe26>] ? __sock_sendmsg+0x48/0x4e
[   29.869117]  [<c11e008f>] ? sock_sendmsg+0x78/0x8f
[   29.869123]  [<c11e008f>] ? sock_sendmsg+0x78/0x8f
[   29.869131]  [<c10c6785>] ? d_kill+0x38/0x3d
[   29.869141]  [<c11e7f0c>] ? verify_iovec+0x3d/0x79
[   29.869147]  [<c11e088d>] ? sys_sendmsg+0x15f/0x1c1
[   29.869153]  [<c11e04c4>] ? sockfd_lookup_light+0x13/0x3f
[   29.869160]  [<c11e0b25>] ? sys_sendto+0xfd/0x121
[   29.869166]  [<c11e43eb>] ? sk_prot_alloc+0x62/0xd6
[   29.869174]  [<c1001e6e>] ? __switch_to+0x6f/0xe2
[   29.869183]  [<c12860de>] ? schedule+0x579/0x5b6
[   29.869190]  [<c11e0723>] ? sys_recvmsg+0x3c/0x47
[   29.869196]  [<c11e1afd>] ? sys_socketcall+0x17f/0x1cb
[   29.869202]  [<c1002f9f>] ? sysenter_do_call+0x12/0x28
[   29.869206] Code: f8 e8 46 25 53 c8 8b 35 ec 45 d5 f8 eb 1a 8b 13 8b 06 e8 17 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 0f 18 00 90 81 fe d0 45 d5 f8 75 d4 83 3d ec 47 d5 f8 
[   29.869249] EIP: [<f8d543cc>] hwrng_register+0x4c/0x139 [rng_core] SS:ESP 0068:f6e5db54
[   29.869259] CR2: 00000000907cde0c
[   29.869264] ---[ end trace 6719399ed79e8cc1 ]---


regards
   Mario
-- 
To err is human. To really foul things up requires a computer.