On Tue, Aug 5, 2014 at 2:02 PM, Nick Krause <xerofoify@gmail.com> wrote:
I am tracing this , Aug 4 10:20:03 Horos kernel: ------------[ cut here ]------------ Aug 4 10:20:03 Horos kernel: WARNING: CPU: 3 PID: 31 at net/wireless/reg.c:1806 reg_process_hint+0x286/0x330 [cfg80211]() Aug 4 10:20:03 Horos kernel: Modules linked in: af_packet snd_pcm_oss snd_mixer_oss nls_iso8859_1 nls_cp850 vfat fat snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi arc4 evdev ath9k ath9k_common ath9k_hw ath psmouse led_class mac80211 k10temp cfg80211 rfkill sr_mod r8169 cdrom mii 8250 serial_core snd_hda_intel snd_hda_controller snd_hda_codec radeon snd_pcm drm_kms_helper button snd_timer ttm processor snd wmi soundcore drm i2c_piix4 i2c_algo_bit i2c_core Aug 4 10:20:03 Horos kernel: CPU: 3 PID: 31 Comm: kworker/3:1 Not tainted 3.16.0-00115-g19583ca #58 Aug 4 10:20:03 Horos kernel: Hardware name: System manufacturer System Product Name/F2A85-M LE, BIOS 5012 08/28/2012 Aug 4 10:20:03 Horos kernel: Workqueue: events reg_todo [cfg80211] Aug 4 10:20:03 Horos kernel: 0000000000000000 ffff880237437d50 ffffffff8134fc09 0000000000000000 Aug 4 10:20:03 Horos kernel: ffff880237437d88 ffffffff81036e05 ffffffffa032dc4b ffff880235677500 Aug 4 10:20:03 Horos kernel: ffff880235ac4240 0000000000000003 ffff88023567751c ffff880237437d98 Aug 4 10:20:03 Horos kernel: Call Trace: Aug 4 10:20:03 Horos kernel: [<ffffffff8134fc09>] dump_stack+0x4d/0x6f Aug 4 10:20:03 Horos kernel: [<ffffffff81036e05>] warn_slowpath_common+0x75/0x8e Aug 4 10:20:03 Horos kernel: [<ffffffffa032dc4b>] ? reg_process_hint+0x286/0x330 [cfg80211] Aug 4 10:20:03 Horos kernel: [<ffffffff81036ec2>] warn_slowpath_null+0x15/0x17 Aug 4 10:20:03 Horos kernel: [<ffffffffa032dc4b>] reg_process_hint+0x286/0x330 [cfg80211] Aug 4 10:20:03 Horos kernel: [<ffffffffa032dd70>] reg_todo+0x7b/0x157 [cfg80211] Aug 4 10:20:03 Horos kernel: [<ffffffff81048e92>] process_one_work+0x1ba/0x2d6 Aug 4 10:20:03 Horos kernel: [<ffffffff81049adb>] worker_thread+0x308/0x3f5 Aug 4 10:20:03 Horos kernel: [<ffffffff810497d3>] ? cancel_delayed_work_sync+0x10/ 0x10 Aug 4 10:20:03 Horos kernel: [<ffffffff8104e13e>] kthread+0xdf/0xe7 Aug 4 10:20:03 Horos kernel: [<ffffffff8104e05f>] ? kthread_create_on_node+0x17b/0x17b Aug 4 10:20:03 Horos kernel: [<ffffffff81353eec>] ret_from_fork+0x7c/0xb0 Aug 4 10:20:03 Horos kernel: [<ffffffff8104e05f>] ? kthread_create_on_node+0x17b/0x17b Aug 4 10:20:03 Horos kernel: ---[ end trace 389490cbf61b0b3c ]---
My logic is this, I am assuming I am wrong again based on my bad patches record. 1. In reg_redo we are calling reg_process_prending_hints with rtnl_lock on this wireless driver 2. In that function we known there are two calls to reg_process_hint and we hit both so therefore, we are traced to that function as also if (lr && !lr->processed) is true in the function we are in 3. In that function we hit the warn on with no default initialization and free the it in the function reg_free_request 4. And since this this is the last request free here and also since this a null value we hit the warn on for null as there is no set function we can use, the request being null 5.We then free the value as this is the last request in reg_free_request based on the if statement and we call reg_process_hint and we have already freed the request leading to the kernel panic Nick 5 is wrong we are freeing the null request as it's last meaning we are calling reg_process_hint again this time as the normal one and not the if statement leading to a kernel panic as the request in null.