On Mon, 2015-01-12 at 09:57 -0500, Ewan Milne wrote: > On Mon, 2015-01-12 at 14:29 +0100, Hannes Reinecke wrote: > > On 01/12/2015 02:12 PM, Ewan Milne wrote: > > > On Thu, 2015-01-08 at 07:43 +0100, Hannes Reinecke wrote: > > >> It is not good practice to display the kernel pointer > > >> in any message logs, and it doesn't display any additional > > >> information. And as we know have block-layer assigned tags > > >> we can use them to differentiate the messages. > > >> So remove any pointer references from the displayed messages. > > >> > > > > > > I'd actually be sad to see this go -- I have found it useful > > > in the past when debugging crash dumps from customer sites > > > to be able to look in the kernel messages and see that a > > > particular scsi_cmnd had been aborted just before the crash > > > (and then later completed). > > > > > But that's precisely why we've prefixed the scmd messages with the > > tag number; with that you'll be able to extract the same information. > > > > And now that hch separated out the block layer tagging from SCSI-2 > > TCQ we should have the tag number available for any command, not > > just those from drivers which use TCQ. > > > > Let me know if that isn't the case; this patch indeed only makes > > sense if the tag number is always available. > > Ah, yes, I think you may be right -- I ran into this when debugging some > double completion panics, so my concern is whether the tag field > remains valid after it completes the first time. I'll check. Looks like if the scmd completes twice, the req could be getting reused, so scmd->request->tag might be different. However, for crash analysis, scmd->tag gets a copy of the request tag so that would be good enough to match up with an earlier logged abort message. Reviewed-by: Ewan D. Milne <emilne@xxxxxxxxxx> -- 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
