- 25 Jul, 2014 11 commits
-
-
Christoph Hellwig authored
Replace the calls to the various blk_end_request variants with opencode equivalents. Blk-mq is using a model that gives the driver control between the bio updates and the actual completion, and making the old code follow that same model allows us to keep the code more similar for both paths. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Webb Scales <webbnh@hp.com> Acked-by:
Jens Axboe <axboe@kernel.dk> Tested-by:
Bart Van Assche <bvanassche@acm.org> Tested-by:
Robert Elliott <elliott@hp.com>
-
Christoph Hellwig authored
This saves us an atomic operation for each I/O submission and completion for the usual case where the driver doesn't set a per-target can_queue value. Only a few iscsi hardware offload drivers set the per-target can_queue value at the moment. Signed-off-by:
-
Christoph Hellwig authored
Seems like these counters are missing any sort of synchronization for updates, as a over 10 year old comment from me noted. Fix this by using atomic counters, and while we're at it also make sure they are in the same cacheline as the _busy counters and not needlessly stored to in every I/O completion. With the new model the _busy counters can temporarily go negative, so all the readers are updated to check for > 0 values. Longer term every successful I/O completion will reset the counters to zero, so the temporarily negative values will not cause any harm. Signed-off-by:
-
Christoph Hellwig authored
Avoid taking the queue_lock to check the per-device queue limit. Instead we do an atomic_inc_return early on to grab our slot in the queue, and if necessary decrement it after finishing all checks. Unlike the host and target busy counters this doesn't allow us to avoid the queue_lock in the request_fn due to the way the interface works, but it'll allow us to prepare for using the blk-mq code, which doesn't use the queue_lock at all, and it at least avoids a queue_lock round trip in scsi_device_unbusy, which is still important given how busy the queue_lock is. Signed-off-by:
-
Christoph Hellwig authored
Avoid taking the host-wide host_lock to check the per-host queue limit. Instead we do an atomic_inc_return early on to grab our slot in the queue, and if necessary decrement it after finishing all checks. Signed-off-by:
-
Christoph Hellwig authored
Avoid taking the host-wide host_lock to check the per-target queue limit. Instead we do an atomic_inc_return early on to grab our slot in the queue, and if necessary decrement it after finishing all checks. Signed-off-by:
-
Christoph Hellwig authored
Prepare for not taking a host-wide lock in the dispatch path by pushing the lock down into the places that actually need it. Note that this patch is just a preparation step, as it will actually increase lock roundtrips and thus decrease performance on its own. Signed-off-by:
-
Christoph Hellwig authored
The blk-mq code path will set this to a different function, so make the code simpler by setting it up in a legacy-request specific place. Signed-off-by:
-
Christoph Hellwig authored
Make sure we only have the logic for requeing commands in one place. Signed-off-by:
-
Christoph Hellwig authored
Factor out a helper to set the _blocked values, which we'll reuse for the blk-mq code path. Signed-off-by:
-
Christoph Hellwig authored
Factor out command setup code that will be shared with the blk-mq code path. Signed-off-by:
-
- 17 Jul, 2014 29 commits
-
-
Christoph Hellwig authored
Signed-off-by:
-
Christoph Hellwig authored
Factor out a function to initialize regular read/write commands and leave sd_init_command as a simple dispatcher to the different prepare routines. Signed-off-by:
-
Christoph Hellwig authored
Currently cmd->allowed is initialized from rq->retries for discard commands, but retries is always 0 for non-BLOCK_PC requests. Set it to the standard number of retries instead. Signed-off-by:
-
Christoph Hellwig authored
Currently cmd->allowed is initialized from rq->retries for write same commands, but retries is always 0 for non-BLOCK_PC requests. Set it to the standard number of retries instead. Signed-off-by:
-
Christoph Hellwig authored
Simplify handling of discard requests by setting up the command directly instead of initializing request fields and then calling scsi_setup_blk_pc_cmnd to propagate the information into the command. Signed-off-by:
-
Christoph Hellwig authored
Simplify handling of write same requests by setting up the command directly instead of initializing request fields and then calling scsi_setup_blk_pc_cmnd to propagate the information into the command. Signed-off-by:
-
Christoph Hellwig authored
Simplify handling of flush requests by setting up the command directly instead of initializing request fields and then calling scsi_setup_blk_pc_cmnd to propagate the information into the command. Also rename scsi_setup_flush_cmnd to sd_setup_flush_cmnd for consistency. Signed-off-by:
-
Christoph Hellwig authored
The data direction fiel in the SCSI command is derived only from the block request structure. Move setting it up into common code instead of duplicating it in the ULDs. Signed-off-by:
-
Christoph Hellwig authored
We should call the device handler prep_fn for all TYPE_FS requests, not just simple read/write calls that are handled by the disk driver. Restructure the common I/O code to call the prep_fn handler and zero out the CDB, and just leave the call to scsi_init_io to the ULDs. Signed-off-by:
-
Christoph Hellwig authored
scsi_init_io should only be called for requests that transfer data, so move the assert that a request has segments from the callers into scsi_init_io. Signed-off-by:
-
Maurizio Lombardi authored
During IO with fabric faults, one generally sees several "Unhandled error code" messages in the syslog as shown below: sd 4:0:6:2: [sdbw] Unhandled error code sd 4:0:6:2: [sdbw] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK sd 4:0:6:2: [sdbw] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sdbw, sector 0 This comes from scsi_io_completion (in scsi_lib.c) while handling error codes other than DID_RESET or not deferred sense keys i.e. this is actually handled by the SCSI mid layer. But what gets displayed here is "Unhandled error code" which is quite misleading as it indicates something that is not addressed by the mid layer. The description string is based on the sense key and sometimes on the additional sense code; since the ACTION_FAIL case always prints the sense key and the additional sense code, this patch removes the description string completely because it does not add useful information. Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Reviewed-by:
-
Douglas Gilbert authored
While checking what scsi_adjust_queue_depth() did I thought its switch statement could be clearer: - remove redundant assignment (to sdev->queue_depth) - re-order cases (thus removing the fall-through) Signed-off-by:
Douglas Gilbert <dgilbert@interlog.com> Reviewed-by:
-
Christoph Hellwig authored
Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Reviewed-by:
-
Bart Van Assche authored
Because of the removal of the scsi_tgt kernel module, the kbuild variables CONFIG_SCSI_TGT, CONFIG_SCSI_SRP_TGT_ATTRS and CONFIG_SCSI_FC_TGT_ATTRS are obsolete. This patch removes these variables. This patch is the result of the following command: find -name '*defconfig' | while read f; do grep -vwE 'CONFIG_SCSI_TGT|CONFIG_SCSI_SRP_TGT_ATTRS|CONFIG_SCSI_FC_TGT_ATTRS|CONFIG_SRP' $f >/tmp/t && mv /tmp/t $f; done Signed-off-by:
-
Bart Van Assche authored
Now that the ibmvstgt driver as the only user of scsi_tgt is gone, the scsi_tgt kernel module, the CONFIG_SCSI_TGT, CONFIG_SCSI_SRP_TGT_ATTRS and CONFIG_SCSI_FC_TGT_ATTRS kbuild variable, the scsi_host_template transfer_response method are no longer needed. [hch: minor updates to the current tree, changelog update] Signed-off-by:
-
Christoph Hellwig authored
Remove the libsrp module which was only used by the now removed ibmvstgt driver. Signed-off-by:
-
Christoph Hellwig authored
The IBM virtual SCSI protocol has been obsoleted by ibmvfc, and there are no reported of the driver left. Signed-off-by:
-
Hannes Reinecke authored
Using dev_printk variants prefixes the logging message with the originating device, which makes debugging easier. Signed-off-by:
-
Hannes Reinecke authored
Signed-off-by:
-
Hannes Reinecke authored
Update the st driver to use dev_printk() variants instead of plain printk(); this will prefix logging messages with the appropriate device. Signed-off-by:
-
Hannes Reinecke authored
Update the ch driver to use dev_printk() variants instead of plain printk(); this will prefix logging messages with the appropriate device. Signed-off-by:
-
Hannes Reinecke authored
Update the sg driver to use dev_printk() variants instead of plain printk(); this will prefix logging messages with the appropriate device. Signed-off-by:
-
Hannes Reinecke authored
Update the sr driver to use dev_printk() variants instead of plain printk(); this will prefix logging messages with the appropriate device. Signed-off-by:
-
Hannes Reinecke authored
scsilun_to_int() has an error which prevents it from generating correct LUN numbers for 64bit values. Also we should remove the misleading comment about portions of the LUN being ignored; the initiator should treat the LUN as an opaque value. And, finally, the example given should use the correct prefix (here: extended flat space addressing scheme). This patch includes the modifications suggested by Bart van Assche. Cc: Bart van Assche <bvanassche@acm.org> Cc: Christoph Hellwig <hch@infradead.org> Signed-off-by:
James Bottomley <jbottomley@parallels.com> Signed-off-by:
-
Hannes Reinecke authored
Now that we're using 64-bit LUNs internally we need to increase the size of max_luns to 64 bits, too. Signed-off-by:
Christoph Hellwig <hch@infradead.org> Reviewed-by:
Ewan Milne <emilne@redhat.com> Signed-off-by:
-
Hannes Reinecke authored
Some driver might want to pass in an 64-bit value, so introduce a module param type 'ullong'. Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Hannes Reinecke authored
The SCSI standard defines 64-bit values for LUNs, and large arrays employing large or hierarchical LUN numbers become more and more common. So update the linux SCSI stack to use 64-bit LUN numbers. Signed-off-by:
-
Hannes Reinecke authored
Older HBAs are only capable of supporting 16-bit LUNs, so we need to make sure to adjust max_lun accordingly. Signed-off-by:
Chad Dupuis <chad.dupuis@qlogic.com> Reviewed-by:
-
Hannes Reinecke authored
Sequential scan for more than 256 LUNs is very fragile as LUNs might not be numbered sequentially after that point. SAM revisions later than SCSI-3 impose a structure on LUNs larger than 256, making LUN numbers between 256 and 16384 illegal. SCSI-3, however allows for plain 64-bit numbers with no internal structure. So restrict sequential LUN scan to 256 LUNs and add a new blacklist flag 'BLIST_SCSI3LUN' to scan up to max_lun devices. Signed-off-by:
-
