On Tue, Aug 5, 2014 at 2:02 PM, Nick Krause <xerofoify@xxxxxxxxx> 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. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
