On Fri, Nov 20, 2015 at 10:26 AM, James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> We can look at it, but the analysis shouldn't be correct.
Just take the five seconds to check the freeing path, please. The last
free is this:
> INFO: Freed in scsi_device_dev_release_usercontext+0x23d/0x2d7 age=4 cpu=0 pid=1
> free_debug_processing+0x188/0x207 mm/slub.c:1108
> scsi_device_dev_release_usercontext+0x23d/0x2d7 drivers/scsi/scsi_sysfs.c:429
> __slab_free+0x4a/0x27a mm/slub.c:2587
> mempool_free_slab+0x0/0x13 mm/mempool.c:453
> ida_remove+0xc6/0x159 lib/idr.c:1042
> __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e ??:?
> __read_once_size include/linux/compiler.h:218
> atomic_read ./arch/x86/include/asm/atomic.h:27
> __rcu_is_watching+0x18/0x1f kernel/rcu/tree.c:987
> scsi_device_dev_release_usercontext+0x23d/0x2d7 drivers/scsi/scsi_sysfs.c:429
> scsi_device_dev_release_usercontext+0x23d/0x2d7 drivers/scsi/scsi_sysfs.c:429
> scsi_device_dev_release_usercontext+0x0/0x2d7 drivers/scsi/scsi_sysfs.c:438
> execute_in_process_context+0x24/0x82 kernel/workqueue.c:2969
> device_release+0x44/0xde drivers/base/core.c:247
> kobject_cleanup lib/kobject.c:631
> kobject_release lib/kobject.c:660
> kref_sub include/linux/kref.h:74
> kref_put include/linux/kref.h:99
> kobject_put+0xbc/0xcf lib/kobject.c:677
> scsi_report_lun_scan+0x27f/0x434 drivers/scsi/scsi_scan.c:1458
> scsi_report_lun_scan+0x0/0x434 drivers/scsi/scsi_scan.c:1053
so clearly the device *was* freed by scsi_report_lun_scan() doing the
scsi_device_put().
> This device
> is the one we first used to issue the report lun scan. Either it's an
> existing device, or we created it specially for the purpose. If it's an
> existing one, that put just releases our reference, but the core still
> has one (there'd have to be a very unusual scan destroy race for the
> core to be releasing a reference to an object it was in process of
> scanning).
A race it may be. Or maybe it's even a kasan bug. But so far, those
kasan reports have been pretty much on the money.
It may be that a possible race is widened by kasan itself slowing things down.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
