On Thu, Jun 16, 2011 at 12:37:55PM -0400, James Bottomley wrote: > On Thu, 2011-06-16 at 18:01 +0200, Heiko Carstens wrote: > > cc'ing Jens (full quote of the original bug report at the end). > > > > I patched the SLUB debugging code so that it includes full call traces > > instead of just the address of the caller of kfree/kmalloc. So here is > > yet another incarnation of what I think is the same use-after-free bug: > > > > What we can see here: while scsi_dispatch_cmd() operates on a scsi_cmnd > > it gets freed via blk_done_softirq(). > > In this specific case scsi_send_log() crashes while trying to dereference > > the SLAB/SLUB poison value. > > But you're crashing in the submit path, not the completion path. > scsi_send_log() is called *before* we dispatch the command, so how on > earth did the command get freed in the completion (softirq) path? Well, I was hoping you would point to something obviously wrong ;) So the only way I can think this could have happened then seems to be something like this sequence: User A -- allocs command User A -- somehow frees command (but still has a reference) User B -- submit path allocs command (gets freed slab again) User A -- frees it again User B -- submit path crashes So looks like I need to add more trace and/or debug code. Sigh. Dunno.. maybe zfcp returns the command twice or something like that; even though there is code in place which should prevent exactly this scenario. -- 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
