Messages in this thread | | | Subject | Re: [PATCH 1/2] pci: host: pci-hyperv: Replace GFP_ATOMIC with GFP_KERNEL in hv_pci_onchannelcallback | From | Jia-Ju Bai <> | Date | Mon, 19 Mar 2018 16:53:52 +0800 |
| |
On 2018/3/19 16:38, Dan Carpenter wrote: > On Sun, Mar 18, 2018 at 10:53:02PM +0800, Jia-Ju Bai wrote: >> hv_pci_onchannelcallback() is not called in atomic context. >> >> The call chain ending up at hv_pci_onchannelcallback() is: >> [1] hv_pci_onchannelcallback() <- hv_pci_probe() >> hv_pci_probe() is only set as ".probe" in hv_driver >> structure "hv_pci_drv". >> > Your static analysis tool is faulty and apparently so is Smatch. > > $ smdb function_ptrs hv_pci_onchannelcallback > > Says it can't find a caller. When I look for function pointers I get: > > $ smdb function_ptr hv_pci_onchannelcallback > hv_pci_onchannelcallback = 'hv_pci_onchannelcallback' , 'vmbus_open param 5' , '(struct vmbus_channel)->onchannel_callback' , '__read_once_size param 0' > > Anyway the call tree is: > > vmbus_chan_sched() <-- takes rcu_read_lock(); > -> vmbus_channel_isr() > -> channel->onchannel_callback() -> which is hv_pci_onchannelcallback(
Thanks for your reply :) I admit my tool produces a false positive for this code... Sorry for my incorrect patch.
Anyway, I find that function pointers are quite hard to analyze in the Linux kernel code, because their usages are often flexible. Have you found a good way to handle function pointers? Or can you recommend some good tools to handle them?
Best wishes, Jia-Ju Bai
| |