lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 9 Jul 2014 08:40:22 +0200
From:	Christoph Hellwig <hch@....de>
To:	"Elliott, Robert (Server Storage)" <Elliott@...com>
Cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Jens Axboe <axboe@...nel.dk>,
	Bart Van Assche <bvanassche@...ionio.com>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 03/14] scsi: centralize command re-queueing in
	scsi_dispatch_fn

On Tue, Jul 08, 2014 at 08:51:30PM +0000, Elliott, Robert (Server Storage) wrote:
> In scsi_lib.c, both scsi_done() and scsi_mq_done() always call
> trace_scsi_dispatch_cmd_done(), so trace_scsi_dispatch_cmd_start()
> should be called before scsi_done() is called.  That way the
> trace will always have a submission to match each completion.
> 
> That means trace should be called before the sdev_state check 
> (which calls scsi_done()).  
>
> I don't know about the scsi_device_blocked check (which just 
> returns).  Should the trace record multiple submissions with 
> one completion?  Maybe both trace_scsi_dispatch_cmd_start() 
> and trace_scsi_dispatch_cmd_done() should both be called?

trace_scsi_dispatch_cmd_start is maybe a little misnamed as it traces
the command submission to the driver.  So getting a done trace without
this one sounds perfectly fine.  Adding another trace for an error
before submission could be done if you care about pairing.  The *_BUSY
returns don't fit this scheme at all.

But none of this really is in this patch.  Hannes has some plans to clean
up the logging and tracing mess in scsi, and it might be a good idea
to incorporate it there.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists