mirror of
https://github.com/lm-sensors/lm-sensors.git
synced 2026-10-17 10:59:31 +00:00
Mark D. Studebaker
b0295fe904
Ticket #1573 -------------- Another update for his issue [kernel panic triggered by bmcsensors}: The source of the problem are the non-atomic kernel mallocs for device registration called from an interrupt context - this doesn't seem to be supported and as observed can crash the kernel. A possible solution is to create a kernel thread on initialisation, leave that thread hanging round while the device scan runs, and finaly signal the init thread when device scan is complete to finish initialisation be registing the sensors found during scan. A patch implementing such a scheme was created by Yvon JEGOU, I'll post it here again. Thanks, Martin -------------- Hi Mark, >> I don't fully understand... sorry if I'm slow. >> is the problem doing mallocs from an interrupt context or non-atomic >> mallocs? >> what's non-atomic about the malloc? >> how did we get in an interrupt context? Being no kernel programmer this is fairly hard form me to answer; lets see how far I get The problem is non-atomic kmallocs from an interrupt context. Non-atomic refers to the flags specified in the kmalloc call (GFP_ATOMIC vs. GFP_KERNEL) (Ref. http://lwn.net/Articles/22909/) Scanning for sensors is triggered by sending an ipmi message in bmcsensors_reserve_sdr. Building the list of sensors and finally creating the required proc entries happens on subsequent reception of ipmi messages in the ipmi call-back. If I understand correctly how things interact, that would be in an interrupt context. Where bmcsensors blows up when trying to register lots of sensors is the -> bmcsensors_command (which is the i2c-ipmi call-back) -> bmcsensors_msg_handler -> bmcsensors_rcv_msg -> bmcsensors_rcv_sdr_msg -> bmcsensors_build_proc_table -> i2c_register_entry -> create_proc_entry -> proc_create -> kmalloc sequence. My limited understanding of kernel programming is that if memory is allocated in an interrupt context, GFP_ATOMIC must be used. While the kmallocs done directly by bmcsensors_build_proc_table would be fixable, the calls in proc_create_entry are obviously not changeable. This makes proc_create and its callers unsafe for use in an interrupt context. The patch works around this limitation by creating a separate kernel thread from sm_bmcsensors_init and calling bmcsensors_build_proc_table from this thread after scanning for sesnsors has finished. Hope I've managed to adequately explain what I think is wrong. Bye, Martin git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2482 7894878c-1315-0410-8ee3-d5d059ff63e0