Trace Help

[Nick Krause]

On Tue, Aug 5, 2014 at 2:02 PM, Nick Krause <xerofoify at 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.