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
