On 10/10/11 13:05, Jonathan Cameron wrote: > Repeatedly hammer insert and removal of devices > triggers a segfault. > > For example: > > [ 205.589608] [<c00d54a0>] (remove_files.isra.1+0x20/0x30) from [<c00d5548>] (sysfs_remove_group+0x98/0xfc) > [ 205.599226] [<c00d5548>] (sysfs_remove_group+0x98/0xfc) from [<c014e468>] (device_remove_groups+0x1c/0x2c) > [ 205.608876] [<c014e468>] (device_remove_groups+0x1c/0x2c) from [<c014e648>] (device_remove_attrs+0x18/0x54) > [ 205.618603] [<c014e648>] (device_remove_attrs+0x18/0x54) from [<c014e790>] (device_del+0x10c/0x170) > [ 205.627636] [<c014e790>] (device_del+0x10c/0x170) from [<c014e800>] (device_unregister+0xc/0x18) > [ 205.636482] [<c014e800>] (device_unregister+0xc/0x18) from [<bf0c6a3c>] (li > s3l02dq_remove+0xe4/0xf4 [lis3l02dq]) > [ 205.646705] [<bf0c6a3c>] (lis3l02dq_remove+0xe4/0xf4 [lis3l02dq]) from [<c016534c>] (spi_drv_remove+0x18/0x1c) > [ 205.656717] [<c016534c>] (spi_drv_remove+0x18/0x1c) from [<c0150c44>] (__device_release_driver+0x7c/0xc0) > [ 205.666272] [<c0150c44>] (__device_release_driver+0x7c/0xc0) from [<c015123c>] (driver_detach+0x8c/0xb4) > [ 205.675731] [<c015123c>] (driver_detach+0x8c/0xb4) from [<c0150b18>] (bus_remove_driver+0x8c/0xb8) > [ 205.684716] [<c0150b18>] (bus_remove_driver+0x8c/0xb8) from [<c00559f8>] (sys_delete_module+0x1f0/0x284) > [ 205.694232] [<c00559f8>] (sys_delete_module+0x1f0/0x284) from [<c000dee0>] (ret_fast_syscall+0x0/0x38) > [ 205.703523] Code: e1a00005 e3a01000 e5932000 ebfff410 (e4943004) > [ 205.715681] ---[ end trace b2c6bfc400ca8dce ]--- > > trying to track it down now. > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Hmm. The cause is a nasty issue to do with the fact we don't unwind the registration of devices in the exact reverse of the way we register them. E.g .we don't have a split between device_unregister and device_free unlike allocate and register. This means there are a few elements created by other core functions that do not have a correct place to be freed. These include some of the attribute groups. Hence we will have to spit the unregister up into unregister which does reverse of register and free which actually frees the struct iio_dev etc. Sorry all about this, I really ought to have realised the problem was there when we first moved to doing the sysfs groups registrations using the dev->groups approach. This is going to involve a couple of changes to every driver unfortunately. I'll put the set together, but could really do with some testing on as many parts as possible. It's still not working quite right so this may take a little while to pin down the fall out. To test, just set up a tight probe remove loop and wait and see if it segfaults on you. Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
