- 24 11月, 2014 1 次提交
-
-
由 Christoph Hellwig 提交于
Drop the now unused reason argument from the ->change_queue_depth method. Also add a return value to scsi_adjust_queue_depth, and rename it to scsi_change_queue_depth now that it can be used as the default ->change_queue_depth implementation. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NMike Christie <michaelc@cs.wisc.edu> Reviewed-by: NHannes Reinecke <hare@suse.de>
-
- 12 11月, 2014 4 次提交
-
-
由 Christoph Hellwig 提交于
Remove the tagged argument from scsi_adjust_queue_depth, and just let it handle the queue depth. For most drivers those two are fairly separate, given that most modern drivers don't care about the SCSI "tagged" status of a command at all, and many old drivers allow queuing of multiple untagged commands in the driver. Instead we start out with the ->simple_tags flag set before calling ->slave_configure, which is how all drivers actually looking at ->simple_tags except for one worke anyway. The one other case looks broken, but I've kept the behavior as-is for now. Except for that we only change ->simple_tags from the ->change_queue_type, and when rejecting a tag message in a single driver, so keeping this churn out of scsi_adjust_queue_depth is a clear win. Now that the usage of scsi_adjust_queue_depth is more obvious we can also remove all the trivial instances in ->slave_alloc or ->slave_configure that just set it to the cmd_per_lun default. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NMike Christie <michaelc@cs.wisc.edu> Reviewed-by: NHannes Reinecke <hare@suse.de> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Christoph Hellwig 提交于
Allow a driver to ask for block layer tags by setting .use_blk_tags in the host template, in which case it will always see a valid value in request->tag, similar to the behavior when using blk-mq. This means even SCSI "untagged" commands will now have a tag, which is especially useful when using a host-wide tag map. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NMike Christie <michaelc@cs.wisc.edu> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NHannes Reinecke <hare@suse.de>
-
由 Christoph Hellwig 提交于
Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NBart Van Assche <bvanassche@acm.org> Reviewed-by: NMike Christie <michaelc@cs.wisc.edu> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NHannes Reinecke <hare@suse.de>
-
由 Christoph Hellwig 提交于
Currently scsi piggy backs on the block layer to define the concept of a tagged command. But we want to be able to have block-level host-wide tags assigned even for untagged commands like the initial INQUIRY, so add a new SCSI-level flag for commands that are tagged at the scsi level, so that even commands without that set can have tags assigned to them. Note that this alredy is the case for the blk-mq code path, and this just lets the old path catch up with it. We also set this flag based upon sdev->simple_tags instead of the block queue flag, so that it is entirely independent of the block layer tagging, and thus always correct even if a driver doesn't use block level tagging yet. Also remove the old blk_rq_tagged; it was only used by SCSI drivers, and removing it forces them to look for the proper replacement. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NMike Christie <michaelc@cs.wisc.edu> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NHannes Reinecke <hare@suse.de>
-
- 04 11月, 2014 1 次提交
-
-
由 Hans de Goede 提交于
With uas over usb-3 the tags inside the uas iu-s must match the usb-3 stream ids, and those go from 1 - qdepth. Before blk-mq calling scsi_activate_tcq(sdev, qdepth) guaranteed that we would only get cmnd->request->tag from 0 - (qdepth - 1), and we used those as uas-tags / stream-ids. With blk-mq however we are guaranteed to never get more then qdepth commands queued at the same time, but the cmnd->request->tag values may be much larger, which breaks uas. This commit fixes this by generating uas tags in the 1 - qdepth range ourselves instead of using cmnd->request->tag. While touching all involved code anyways also rename the uas_cmd_info stream field to uas_tag, because when using uas over usb-2 streams are not used. Cc: Christoph Hellwig <hch@infradead.org> Reported-by: NDouglas Gilbert <dgilbert@interlog.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> -- Changes in v2: -Remove ".disable_blk_mq = true" from uas_host_template Changes in v3: -Rebased on top of Linus' current master branch Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 04 10月, 2014 1 次提交
-
-
由 Hans de Goede 提交于
The stream_id and pipe are already present in uas_cmd_info resp uas_dev_info, so there is no need to pass a copy along. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 03 10月, 2014 1 次提交
-
-
由 Christoph Hellwig 提交于
The uas driver uses the block layer tag for USB3 stream IDs. With blk-mq we can get larger tag numbers that the queue depth, which breaks this assumption. A fix is under way for 3.18, but sits on top of large changes so can't easily be backported. Set the disable_blk_mq path so that a uas device can't easily crash the system when using blk-mq for SCSI. Signed-off-by: NChristoph Hellwig <hch@lst.de> Acked-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
-
- 24 9月, 2014 26 次提交
-
-
由 Hans de Goede 提交于
If something goes wrong in our communication with an uas device we may get a response iu in reaction to a cmnd, rather then a status iu. In this case propagate an error upwards, rather then logging a bogus iu message. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Instead of doing: uas_log_cmd_state(cmnd, __func__) scmd_printk(KERN_ERR, cmnd, "error doing foo %d\n", err) On error, resulting in 2 log calls for a single error, make uas_log_cmd_state take a status code, and change calls like the above to: uas_log_cmd_state(cmnd, "error doing foo", err) Also change various sanity checks (which should never trigger) from: "scmd_printk(KERN_ERR, cmnd, "sanity foo failed\n")" to calling the new uas_log_cmd_state(), so that when they do trigger we get more info. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
We've removed all hack from the driver for pre-production hardware. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
I've access to a number of different uas devices now, and none of them use old style sense urbs. The only case where these code-paths trigger is with the asm1051 and there they do the wrong thing, as the asm1051 sends 8 bytes status iu-s when it does not have any sense data, but uses new style sense iu-s regardless, as can be seen for scsi cmnds where there is sense data. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
It was only used to sanity check against completing the same cmnd twice, but that is the case we're likely operating on free-ed memory, and doing sanity checks on free-ed memory is not really helpful. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Use scsi_print_command to print commands during errors, rather then printing the rather meaningless pointer to the command. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Check for both type of cancellation codes for sense and data urbs. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Limit the no-streams case to speeds less then USB_SPEED_SUPER. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
The purpose of uas_pre_reset is to: 1) Stop any new commands from being submitted while an externally triggered usb-device-reset is running 2) Wait for any pending commands to finish before allowing the usb-device-reset to continue The purpose of uas_suspend is to: 2) Wait for any pending commands to finish before suspending This commit fixes races in both paths: 1) For 1) we use scsi_block_requests, but the scsi midlayer calls queuecommand without holding any locks, so a queuecommand may already past the midlayer scsi_block_requests checks when we call it, add a check to uas_queuecommand to fix this 2) For 2) we were waiting for all sense-urbs to complete, there are 2 problems with this approach: a) data-urbs may complete after the sense urb, so we need to check for those too b) if a sense-urb completes with a iu id of READ/WRITE_READY a command is not yet done. We submit a new sense-urb immediately in this case, but that submit may fail (in which case it will get retried by uas_do_work), if this happens the sense_urbs anchor may become empty while the cmnd is not yet done Also unblock requests on timeout, to avoid things getting stuck in that case. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Not all urbs we've allocated are necessarily also submitted, non-submitted urbs will not be free-ed by their completion handler. So we need to free them manually. There are 2 scenarios where this can happen: 1) We have failed to submit some urbs at abort / disconnect 2) When running over usb-2 we may have never tried to submit the data urbs when completing the scsi cmnd, because we never got a READ/WRITE_READY iu Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Do not keep references around to a cmnd which is under error handling. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
It is not strictly necessary for the cmd urb to have a reference to the cmnd, and without this reference it becomes easier to drop all references to a cmnd on an abort. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
We've the same info doubled in both the inflight list and the cmnd array, drop the list. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
The data urbs are all killed before calling zap_pending, and their completion handler should have cleared their inflight flag. Do not 0 the data inflight flags, and add a check for try_complete succeeding, as it should always succeed when called from zap_pending. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Drop the whole dance with first moving cmnds to a dead-list. The resetting flag ensures that no new cmds / urbs will be submitted, and that any urb completions are short-circuited without trying to complete the scsi cmnd. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Now that we no longer drop our lock to unlink the data urbs, we can simply free them on completion, making their handling consistent with the other urbs. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
There is no need for all the trickery with dropping the lock, we can simply reference the urbs while we hold the lock to ensure the urbs don't disappear beneath us, and do the actual unlink (+ unreference) after we've dropped the lock. This also fixes a race where we may loose of cmnd ownership to the scsi midlayer without holding the lock due to the midlayer re-claiming ownership through an abort (which will be handled by a future patch in this series). Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
The status urb should not complete before the command has been submitted, nor should we get a second status urb for the same tag after a IU_ID_STATUS. Data urbs should not complete before the command has been submitted, but may complete after the IU_ID_STATUS. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Using scsi_host_find_tag with tags returned by the device is unsafe for multiple reasons: 1) It returns tags->rqs[tag], which may be non NULL even when the cmnd is not owned by us 2) It returns tags->rqs[tag], without holding any locks protecting it 3) It returns tags->rqs[tag], without doing any boundary checking Instead keep our own list which maps tags -> inflight cmnds. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Factor out the mapping of scsi-tags -> uas-tags/stream-ids to a helper function so that there is a single place where this "magic" happens. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
- Make sure we always hold the lock when setting / checking resetting - Check resetting before checking urb->status - Add missing check for resetting to uas_data_cmplt - Add missing check for resetting to uas_do_work Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
There are various bug reports about oopses / hangs with the uas driver, which all point to the abort-command and logical-unit-reset (task-management) error handling paths. Getting these right is very hard, there are quite a few corner cases, and testing is almost impossible since under normal operation these code paths are not used at all. Another problem is that there are also some cases where it simply is not clear what to do at all. E.g. over usb-2 multiple outstanding commands share the same endpoint. What if a command gets aborted while its sense urb is half way through completing (so some data has been transfered but not all). Since the urb is not yet complete we don't know if the sense urb is actually for this command, or for one of the other oustanding commands. If it is for one of the other commands and we cancel it, then we end up in an undefined state. But if it is actually for the command we're aborting, and the abort succeeds, then it may never complete... This exact same problem applies to logical unit resets too, if there are multiple luns, then commands outstanding on both luns share the sense endpoint. If there is only a single lun, then doing a logical unit reset is little better then doing a full usb device reset. So summarizing because: 1) abort / lun-reset is very tricky to get right 2) Not being able to test the tricky code, which means it will have bugs 3) This being a code path which under normal operation will never happen, so being slow / sub-optimal here is not really an issue 4) Under error conditions we will still be able to recover through usb device resets. 5) This may be a bit slower in some cases, but this is actually faster in cases where the bridge ship has locked up, which seems to be the most common error case sofar. This commit removes the abort / lun-reset error handling paths, and also the taks-mgmt code since those are the only 2 task-mgmt users. Leaving only the (tested and testable) usb-device-reset error handling path in place. Note I realize that this is somewhat of a big hammer, but currently people are seeing very hard to debug oopses with uas. First let focus on making uas work reliable, then we can later look into adding more fine grained error handling. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Besides the ASM1051 (*) needing sdev->no_report_opcodes = 1, it turns out that the JMicron JMS567 also needs it to work properly with uas (usb-storage always sets it). Since some of the scsi devs were not to keen on the idea to outrightly set sdev->no_report_opcodes = 1 for all uas devices, so add a quirk for this, and set it for the JMS567. *) Which has become a non-issue since we've completely blacklisted uas on the ASM1051 for other reasons Cc: stable@vger.kernel.org Reported-and-tested-by: NClaudio Bizzarri <claudio.bizzarri@gmail.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
And set this quirk for the Seagate Expansion Desk (0bc2:2312), as that one seems to hang upon receiving an ATA_12 or ATA_16 command. https://bugzilla.kernel.org/show_bug.cgi?id=79511 https://bbs.archlinux.org/viewtopic.php?id=183190 While at it also add missing documentation for the u value for usb-storage quirks. Cc: stable@vger.kernel.org # 3.16, 3.17 Signed-off-by: NHans de Goede <hdegoede@redhat.com> -- Changes in v2: Add documentation for new t and u usb-storage.quirks flags Changes in v3: Fix typo in documentation Changes in v4: Also apply the quirk to (0bc2:3312) Changes in v5: Rebased on 3.17-rc5, drop u documentation, already upstream Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Sanjeev Sharma 提交于
on some architecture spin_is_locked() always return false in uniprocessor configuration and therefore it would be advise to replace with lockdep_assert_held(). Signed-off-by: NSanjeev Sharma <Sanjeev_Sharma@mentor.com> Acked-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 02 8月, 2014 1 次提交
-
-
由 Hans de Goede 提交于
Some jmicron uas chipsets act up (they disconnect from the bus) when sending more then 32 commands to them at once. Rather then building an ever growing list with usb-id based quirks for devices using this chipset, simply reduce the qdepth to 32 when connected over usb-2. 32 should be plenty to keep things close to maximum possible throughput on usb-2. Cc: stable@vger.kernel.org Tested-and-reported-by: NLaszlo T. <tlacix@gmail.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 17 4月, 2014 3 次提交
-
-
由 Oliver Neukum 提交于
There are also two allocations with GFP_KERNEL in the pre-/post_reset code paths. That is no good because that is a part of the SCSI error handler. Signed-off-by: NOliver Neukum <oliver@neukum.org> Reviewed-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Oliver Neukum 提交于
intfdata is set only after scsi_scan(). uas_pre_reset() however needs intfdata to be valid and will follow the NULL pointer killing khubd. intfdata must be preemptively set before the host is registered and undone in the error case. Signed-off-by: NOliver Neukum <oliver@neukum.org> Reviewed-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Oliver Neukum 提交于
Quote Dan: The patch e36e6493: "uas: Use GFP_NOIO rather then GFP_ATOMIC where possible" from Nov 7, 2013, leads to the following static checker warning: drivers/usb/storage/uas.c:806 uas_eh_task_mgmt() error: scheduling with locks held: 'spin_lock:lock' Some other allocations under spinlock are not caught. The fix essentially reverts e36e6493Signed-off-by: NOliver Neukum <oliver@neukum.org> Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 05 3月, 2014 2 次提交
-
-
由 Hans de Goede 提交于
Although an interesting concept, I don't think that this is a good idea: -This will result in lots of "virtual" scsi controllers confusing users -If we get a scsi-bus-reset we will now need to do a usb-device-reset of all uas devices on the same usb bus, which is something to avoid if possible Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Hans de Goede 提交于
At the kernel-summit Sarah Sharp asked me if I was willing to become the uas maintainer. I said yes, and here is a patch to make this official. Also remove Matthew Wilcox and Sarah Sharp as maintainers at their request. I've also added myself to the module's author tag, so that if people look there rather then in maintainers they will know they should bug me about uas too. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-