Re: [PATCH v2] kref: warn on uninitialized kref
On Sat, May 17, 2014 at 05:14:13PM -0400, Mikulas Patocka wrote:
BTW. if we talk about performance - what about replacing:
if (atomic_dec_and_test(variable)) {
... release(object);
}
with this:
if (atomic_read(variable) == 1 || atomic_dec_and_test(variable)) {
barrier();
... release(object);
}
That would completely wreck kref_get_unless_zero().
pgpVP1oQ2uYC6.pgp
Description: PGP signature
Re: scsi error handling thread and REQUEST SENSE
On 05/16/2014 10:05 PM, Ewan Milne wrote: On Fri, 2014-05-16 at 19:02 +, Elliott, Robert (Server Storage) wrote: There is an issue with a command timeout followed by a failed abort in the linux SCSI stack. This might explain some odd crashes I've seen, where it looks like a command might have completed *long* after it should have timed out. I have a few questions, see below: After triggering a timeout on a command like: [ 5454.196861] sd 2:0:0:1: [sds] Done: TIMEOUT [ 5454.196863] sd 2:0:0:1: [sds] Result: hostbyte=DID_OK driverbyte=DRIVER_OK [ 5454.196866] sd 2:0:0:1: [sds] CDB: Mode Sense(10): 5a 00 03 00 00 00 00 00 04 00 scsi_times_out() invokes scsi_abort_command(): [ 5454.196880] sd 2:0:0:1: [sds] scmd 880428963a70 abort scheduled and scmd_eh_abort_handler() tries to abort the command: [ 5454.206828] sd 2:0:0:1: [sds] aborting command 880428963a70 If the abort fails (with return value FAILED (0x2003 == 8195)): [ 5454.206832] sd 2:0:0:1: [sds] scmd 880428963a70 abort failed, rtn 8195 then scmd_eh_abort_handler() just gives up and expects the error handler thread to deal with the problem. When that thread (scsi_error_handler()) wakes up later on, it finds this command (and others) outstanding: [ 5454.373581] scsi_eh_2: waking up 0/3/3 [ 5454.375037] sd 2:0:0:1: scsi_eh_prt_fail_stats: cmds failed: 1, cancel: 0 [ 5454.377332] sd 2:0:0:11: scsi_eh_prt_fail_stats: cmds failed: 2, cancel: 0 [ 5454.379779] Total of 3 commands on 2 devices require eh work For each command, it starts with this check: #define SCSI_SENSE_VALID(scmd) \ (((scmd)-sense_buffer[0] 0x70) == 0x70) if ((scmd-eh_eflags SCSI_EH_CANCEL_CMD) || SCSI_SENSE_VALID(scmd)) continue; In this case, that if statement fails. The eflags bit is not set, and the sense data buffer still contains zeros or garbage - the command is still outstanding, so the buffer might be written at any time. (the sense buffer shouldn't be read unless a valid bit says it's filled in, and this lacks support for descriptor format sense data (type 0x72), but those are side issues) Doesn't the check for: (byte[0] 0x70) == 0x70 cover 0x70 - 0x73? Strangely, the error handler code (scsi_unjam_host()) proceeds to send a REQUEST SENSE command and sees the resulting sense key of NO SENSE: [ 5454.381659] sd 2:0:0:1: [sds] scsi_eh_2: requesting sense [ 5454.383597] scsi_eh_done scmd: 880428963a70 result: 0 [ 5454.385457] sd 2:0:0:1: [sds] Done: UNKNOWN [ 5454.387430] sd 2:0:0:1: [sds] Result: hostbyte=DID_OK driverbyte=DRIVER_OK [ 5454.390450] sd 2:0:0:1: [sds] CDB: Request Sense: 03 00 00 00 60 00 [ 5454.393497] scsi_send_eh_cmnd: scmd: 880428963a70, timeleft: 9998 [ 5454.395667] scsi_send_eh_cmnd: scsi_eh_completed_normally 2002 [ 5454.397842] sense requested for 880428963a70 result 0 [ 5454.399675] sd 2:0:0:1: [sds] Sense Key : No Sense [current] [ 5454.402570] sd 2:0:0:1: [sds] Add. Sense: No additional sense information So, a command timed out, the abort didn't succeed, but a REQUEST SENSE completed normally? What kernel was this? Did it have the change to issue the abort in the timeout handler rather than the EH thread? It seems like it does, based on your description above. However, I'm wondering because I have seen crashes on kernels both with and without that change. The bogus UNKNOWN print is being fixed by Hannes' logging patch. It just means the REQUEST SENSE command was submitted successfully. This device uses autosense, so REQUEST SENSE is not a valid way to find out any information for the timed out command. There is no contingent allegiance condition stalling the queue until REQUEST SENSE comes along to collect the sense data - that parallel SCSI concept went obsolete in SAM-3 revision 5 in January 2003. The command is still outstanding; data transfers might still occur, and a completion using its tag could still appear at any time. However, the error handler declares that the command is done, so all the buffers are freed and the tag is reused. The SCSI error handler needs to escalate this to a reset that ensures that the command is no longer outstanding: ABORT TASK (which already didn't work), ABORT TASK SET, LOGICAL UNIT RESET, I_T NEXUS RESET, or hard reset. What is supposed to happen is that the EH will escalate and eventually reset the HBA if all else fails. It definitely should not be returning the scmd if the LLD is still using it. Well, problem here is that the 'REQUEST SENSE' command has two problems: a) Most modern HBA (ie all non-SPI HBAs) use autosense, ie the sense code is returned with the command. So issuing 'REQUEST SENSE' here is pointless. b) The sense code (when retrieved via 'REQUEST SENSE') relates to the most recently processed command (from the target perspective). Which is a bit hard to make out, as by the time SCSI EH starts several other commands might have been processed already, so any
Re: scsi error handling thread and REQUEST SENSE
On 05/19/14 10:32, Hannes Reinecke wrote: Well, problem here is that the 'REQUEST SENSE' command has two problems: a) Most modern HBA (ie all non-SPI HBAs) use autosense, ie the sense code is returned with the command. So issuing 'REQUEST SENSE' here is pointless. b) The sense code (when retrieved via 'REQUEST SENSE') relates to the most recently processed command (from the target perspective). Which is a bit hard to make out, as by the time SCSI EH starts several other commands might have been processed already, so any sense we'd be retrieving most likely does not relate to the failed command. I would propose to disable the 'REQUEST_SENSE' step as soon as the HBA is capable of autosensing. We requires us to add another flag to the scsi_host field. What about the attached patch? That should roughly do what's required here, right? This patch does not address the SRP initiator. There might be more SCSI initiator drivers that support autosense but that are not addressed by this patch. Has it been considered to set the autosense flag for all HBA's and clear it in those SCSI initiator drivers that do not support autosense ? Bart. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 76241] USB Device Not Recognised
https://bugzilla.kernel.org/show_bug.cgi?id=76241 Alan a...@lxorguk.ukuu.org.uk changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution|--- |OBSOLETE --- Comment #2 from Alan a...@lxorguk.ukuu.org.uk --- 2.6.27 is obsolete. -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi error handling thread and REQUEST SENSE
On 05/19/2014 12:29 PM, Bart Van Assche wrote: On 05/19/14 10:32, Hannes Reinecke wrote: Well, problem here is that the 'REQUEST SENSE' command has two problems: a) Most modern HBA (ie all non-SPI HBAs) use autosense, ie the sense code is returned with the command. So issuing 'REQUEST SENSE' here is pointless. b) The sense code (when retrieved via 'REQUEST SENSE') relates to the most recently processed command (from the target perspective). Which is a bit hard to make out, as by the time SCSI EH starts several other commands might have been processed already, so any sense we'd be retrieving most likely does not relate to the failed command. I would propose to disable the 'REQUEST_SENSE' step as soon as the HBA is capable of autosensing. We requires us to add another flag to the scsi_host field. What about the attached patch? That should roughly do what's required here, right? This patch does not address the SRP initiator. There might be more SCSI initiator drivers that support autosense but that are not addressed by this patch. Has it been considered to set the autosense flag for all HBA's and clear it in those SCSI initiator drivers that do not support autosense ? Correct. I haven't looked at the SRP spec to figure out if it does autosense or not. If it does we should be updating the patch. And yes, it has been considered. However, I decided against it because it would require to check each and every driver to figure out if they do autosense or not. So as a first test I decided it to be quicker to have a 'whitelist' kind of approach and enable only those for which autosense is required by protocol. This also excludes all RAID HBAs, which need to be checked individually. And the SPI HBAs, of course. Plus this is just a test patch, nothing official yet. I'm happy to include the changes for SRP if you can confirm that SRP requires autosense. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi error handling thread and REQUEST SENSE
On 05/19/14 12:37, Hannes Reinecke wrote: Plus this is just a test patch, nothing official yet. I'm happy to include the changes for SRP if you can confirm that SRP requires autosense. Hello Hannes, Since the SRP protocol supports returning sense data in the SRP response message and since every SRP target system I'm familiar with supports command queueing I think it is safe to enable the autosense feature in the SRP initiator driver. Bart. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi: dc395x.c: Fix for possible null pointer dereference
On Sun, 2014-05-18 at 21:50 +0200, Guennadi Liakhovetski wrote: On Sun, 18 May 2014, Rickard Strandqvist wrote: There is otherwise a risk of a possible null pointer dereference. Was largely found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se --- drivers/scsi/dc395x.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c index 83d9bf6..0d86bc7 100644 --- a/drivers/scsi/dc395x.c +++ b/drivers/scsi/dc395x.c @@ -2637,7 +2637,7 @@ static struct ScsiReqBlk *msgin_qtag(struct AdapterCtlBlk *acb, struct ScsiReqBlk *srb = NULL; struct ScsiReqBlk *i; dprintkdbg(DBG_0, msgin_qtag: (0x%p) tag=%i srb=%p\n, - srb-cmd, tag, srb); + srb ? srb-cmd : 0, tag, srb); There's not just a risk, it is a NULL-pointer dereference, so, just remove it, e.g. like Indeed. Thank you both for catching this. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi error handling thread and REQUEST SENSE
On 05/16/14 21:02, Elliott, Robert (Server Storage) wrote: The command is still outstanding; data transfers might still occur, and a completion using its tag could still appear at any time. However, the error handler declares that the command is done, so all the buffers are freed and the tag is reused. The SCSI error handler needs to escalate this to a reset that ensures that the command is no longer outstanding: ABORT TASK (which already didn't work), ABORT TASK SET, LOGICAL UNIT RESET, I_T NEXUS RESET, or hard reset. If my interpretation of the SCSI mid-layer source code is correct then even with the patch improved eh timeout handler applied the SCSI mid-layer still guarantees for each SCSI host that at most one eh_abort_handler() call is active at any given time (since tmf_work_q is created with max_active = 1) and also that at least one of the eh_* functions is invoked before the SCSI mid-layer finishes a command. Does your comment mean that you have found a scenario in which none of the LLD eh_* callback functions was invoked before the SCSI mid-layer finished a SCSI command ? Thanks, Bart. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bnx2i: Make boot_nic entry visible in the sysfs session objects
From: Tej Parkash tej.park...@qlogic.com Signed-off-by: Tej Parkash tej.park...@qlogic.com Signed-off-by: Vikas Chaudhary vikas.chaudh...@qlogic.com --- drivers/scsi/bnx2i/bnx2i_iscsi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c b/drivers/scsi/bnx2i/bnx2i_iscsi.c index 166543f..cabc8c1 100644 --- a/drivers/scsi/bnx2i/bnx2i_iscsi.c +++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c @@ -2234,6 +2234,9 @@ static umode_t bnx2i_attr_is_visible(int param_type, int param) case ISCSI_PARAM_TGT_RESET_TMO: case ISCSI_PARAM_IFACE_NAME: case ISCSI_PARAM_INITIATOR_NAME: + case ISCSI_PARAM_BOOT_ROOT: + case ISCSI_PARAM_BOOT_NIC: + case ISCSI_PARAM_BOOT_TARGET: return S_IRUGO; default: return 0; -- 1.8.2.GIT -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi error handling thread and REQUEST SENSE
On Mon, 2014-05-19 at 10:32 +0200, Hannes Reinecke wrote: On 05/16/2014 10:05 PM, Ewan Milne wrote: On Fri, 2014-05-16 at 19:02 +, Elliott, Robert (Server Storage) wrote: There is an issue with a command timeout followed by a failed abort in the linux SCSI stack. This might explain some odd crashes I've seen, where it looks like a command might have completed *long* after it should have timed out. I have a few questions, see below: After triggering a timeout on a command like: [ 5454.196861] sd 2:0:0:1: [sds] Done: TIMEOUT [ 5454.196863] sd 2:0:0:1: [sds] Result: hostbyte=DID_OK driverbyte=DRIVER_OK [ 5454.196866] sd 2:0:0:1: [sds] CDB: Mode Sense(10): 5a 00 03 00 00 00 00 00 04 00 scsi_times_out() invokes scsi_abort_command(): [ 5454.196880] sd 2:0:0:1: [sds] scmd 880428963a70 abort scheduled and scmd_eh_abort_handler() tries to abort the command: [ 5454.206828] sd 2:0:0:1: [sds] aborting command 880428963a70 If the abort fails (with return value FAILED (0x2003 == 8195)): [ 5454.206832] sd 2:0:0:1: [sds] scmd 880428963a70 abort failed, rtn 8195 then scmd_eh_abort_handler() just gives up and expects the error handler thread to deal with the problem. When that thread (scsi_error_handler()) wakes up later on, it finds this command (and others) outstanding: [ 5454.373581] scsi_eh_2: waking up 0/3/3 [ 5454.375037] sd 2:0:0:1: scsi_eh_prt_fail_stats: cmds failed: 1, cancel: 0 [ 5454.377332] sd 2:0:0:11: scsi_eh_prt_fail_stats: cmds failed: 2, cancel: 0 [ 5454.379779] Total of 3 commands on 2 devices require eh work For each command, it starts with this check: #define SCSI_SENSE_VALID(scmd) \ (((scmd)-sense_buffer[0] 0x70) == 0x70) if ((scmd-eh_eflags SCSI_EH_CANCEL_CMD) || SCSI_SENSE_VALID(scmd)) continue; In this case, that if statement fails. The eflags bit is not set, and the sense data buffer still contains zeros or garbage - the command is still outstanding, so the buffer might be written at any time. (the sense buffer shouldn't be read unless a valid bit says it's filled in, and this lacks support for descriptor format sense data (type 0x72), but those are side issues) Doesn't the check for: (byte[0] 0x70) == 0x70 cover 0x70 - 0x73? Strangely, the error handler code (scsi_unjam_host()) proceeds to send a REQUEST SENSE command and sees the resulting sense key of NO SENSE: [ 5454.381659] sd 2:0:0:1: [sds] scsi_eh_2: requesting sense [ 5454.383597] scsi_eh_done scmd: 880428963a70 result: 0 [ 5454.385457] sd 2:0:0:1: [sds] Done: UNKNOWN [ 5454.387430] sd 2:0:0:1: [sds] Result: hostbyte=DID_OK driverbyte=DRIVER_OK [ 5454.390450] sd 2:0:0:1: [sds] CDB: Request Sense: 03 00 00 00 60 00 [ 5454.393497] scsi_send_eh_cmnd: scmd: 880428963a70, timeleft: 9998 [ 5454.395667] scsi_send_eh_cmnd: scsi_eh_completed_normally 2002 [ 5454.397842] sense requested for 880428963a70 result 0 [ 5454.399675] sd 2:0:0:1: [sds] Sense Key : No Sense [current] [ 5454.402570] sd 2:0:0:1: [sds] Add. Sense: No additional sense information So, a command timed out, the abort didn't succeed, but a REQUEST SENSE completed normally? What kernel was this? Did it have the change to issue the abort in the timeout handler rather than the EH thread? It seems like it does, based on your description above. However, I'm wondering because I have seen crashes on kernels both with and without that change. The bogus UNKNOWN print is being fixed by Hannes' logging patch. It just means the REQUEST SENSE command was submitted successfully. This device uses autosense, so REQUEST SENSE is not a valid way to find out any information for the timed out command. There is no contingent allegiance condition stalling the queue until REQUEST SENSE comes along to collect the sense data - that parallel SCSI concept went obsolete in SAM-3 revision 5 in January 2003. The command is still outstanding; data transfers might still occur, and a completion using its tag could still appear at any time. However, the error handler declares that the command is done, so all the buffers are freed and the tag is reused. The SCSI error handler needs to escalate this to a reset that ensures that the command is no longer outstanding: ABORT TASK (which already didn't work), ABORT TASK SET, LOGICAL UNIT RESET, I_T NEXUS RESET, or hard reset. What is supposed to happen is that the EH will escalate and eventually reset the HBA if all else fails. It definitely should not be returning the scmd if the LLD is still using it. Well, problem here is that the 'REQUEST SENSE' command has two problems: a) Most modern HBA (ie all non-SPI HBAs) use autosense, ie the sense code is returned with the command. So issuing 'REQUEST SENSE' here is pointless. b)
[REPOST v2] [PATCH 1/1] lpfc: Add iotag memory barrier
Prior patch still had a whitespace error. This should be the good one. --- Checkpatch wants comments prior to mb() insertions. A good idea. Added the comments. --- Add a memory barrier to ensure the valid bit is read before any of the cqe payload is read. This fixes an issue seen on Power where the cqe payload was getting loaded before the valid bit. When this occurred, we saw an iotag out of range error when a command completed, but since the iotag looked invalid the command didn't get completed to scsi core. Later we hit the command timeout, attempted to abort the command, then waited for the aborted command to get returned. Since the adapter already returned the command, we timeout waiting, and end up escalating EEH all the way to host reset. This patch fixes this issue. Signed-off-by: Brian King brk...@linux.vnet.ibm.com Signed-off-by: James Smart james.sm...@emulex.com --- lpfc_sli.c | 21 + 1 file changed, 21 insertions(+) diff -upNr a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c --- a/drivers/scsi/lpfc/lpfc_sli.c 2014-03-31 16:21:37.0 -0400 +++ b/drivers/scsi/lpfc/lpfc_sli.c 2014-05-07 17:15:05.057890521 -0400 @@ -265,6 +265,16 @@ lpfc_sli4_eq_get(struct lpfc_queue *q) return NULL; q-hba_index = idx; + + /* +* insert barrier for instruction interlock : data from the hardware +* must have the valid bit checked before it can be copied and acted +* upon. Given what was seen in lpfc_sli4_cq_get() of speculative +* instructions allowing action on content before valid bit checked, +* add barrier here as well. May not be needed as content is a +* single 32-bit entity here (vs multi word structure for cq's). +*/ + mb(); return eqe; } @@ -370,6 +380,17 @@ lpfc_sli4_cq_get(struct lpfc_queue *q) cqe = q-qe[q-hba_index].cqe; q-hba_index = idx; + + /* +* insert barrier for instruction interlock : data from the hardware +* must have the valid bit checked before it can be copied and acted +* upon. Speculative instructions were allowing a bcopy at the start +* of lpfc_sli4_fp_handle_wcqe(), which is called immediately +* after our return, to copy data before the valid bit check above +* was done. As such, some of the copied data was stale. The barrier +* ensures the check is before any data is copied. +*/ + mb(); return cqe; } -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] scsi patch queue tree
I'd like to announce the new scsi patch queue tree, which will pick up any scsi core or driver patches promptly to allow easy integration and feedback that contributors might be used to from other kernel subsystems. There are two branches, one for the SCSI core and upper level drivers, and one for low-level (hardware) drivers: git://git.infradead.org/users/hch/scsi-queue.git core-for-3.16 git://git.infradead.org/users/hch/scsi-queue.git drivers-for-3.16 The rules for the tree are: - it has at least two positive reviews (non-author signoff, reviewed-by or acked-by tags). In practice this means it had at least one and I added another one. - no negative review on the mailing list - it applies cleanly - it compiles cleanly (drivers for architectures I can't test excluded) - for core the core branch: survives a full xfstests run I went through the linux-scsi archives for March, April and May and applied all patches that clearly fit the above criteria, but it's fairly like I missed some. If I'm missing your patch(es): - resend it unless it was sent in the last few weeks - make sure all reviews are recorded in the most recent post of the patch(es) - ping the list for additional reviewers For now the prime intent of the tree is to feed it to James, although I'd welcome everyone interested to pull and test it. If the scheme proves successful I'd love to invite more core scsi contributors to help with it and move to a shared kernel.org tree. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REPOST v2] [PATCH 1/1] lpfc: Add iotag memory barrier
On Mon, May 19, 2014 at 10:04:29AM -0400, James Smart wrote: Prior patch still had a whitespace error. This should be the good one. FYI, I fixed thos manually when I picked up the patch for the scsi-queue tree. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: misc driver updates
I'm still looking for one more review for each of the patches. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dangling pointers and/or reentrancy in scmd_eh_abort_handler?
Hi all, I'm trying to understand asynchronous abort in the current upstream code, and the code seems to have some dubious locking. Here are some examples of the issue: 1) dangling pointers: scsi_put_command calls cancel_delayed_work(), but that doesn't mean that the scmd_eh_abort_handler couldn't be already running. If the scmd_eh_abort_handler starts while the softirq handler is calling scsi_put_command (e.g. scsi_finish_command - scsi_io_completion - scsi_end_request - scsi_next_command), the pointer to the Scsi_Cmnd* becomes invalid in the middle of the abort handler. 2) reentrancy: the softirq handler and scmd_eh_abort_handler can run concurrently, and call scsi_finish_command without any lock protecting the calls. You can then get memory corruption. I don't have any reproducer for this; we're seeing related crashes in virtio-scsi EH but those are due to a bug in the driver. But it means that I have no sensible way to write the eh_abort_handler. Example (1) means that the eh_abort_handler cannot use the passed Scsi_Cmnd, because it might not even be valid when entering the eh_abort_handler. Example (2) means that the eh_abort_handler cannot return SUCCESS if it detects that the command has been completed in the meanwhile. Paolo -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tgt infrastructure removal
Any comments on this series? The last time the subject came up in http://marc.info/?t=13905694535r=1w=2 Tomo said: I'm not sure there are any users of the driver. I guess that you could try to remove the driver to see if someone would complain. and Hannes brought up a mysteria out of tree user in SLES that so far hasn't complained. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dangling pointers and/or reentrancy in scmd_eh_abort_handler?
On 05/19/14 16:08, Paolo Bonzini wrote: 2) reentrancy: the softirq handler and scmd_eh_abort_handler can run concurrently, and call scsi_finish_command without any lock protecting the calls. You can then get memory corruption. I'm not sure what the recommended approach is to address this race. But it is possible to address this in the LLD. See e.g. the srp_claim_req() function in the SRP LLD and how it is invoked from the reply handler, the abort handler and the reset handlers in that LLD. Bart. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: scsi error handling thread and REQUEST SENSE
-Original Message- From: James Bottomley [mailto:jbottom...@parallels.com] Sent: Monday, 19 May, 2014 8:42 AM To: h...@suse.de Cc: linux-scsi@vger.kernel.org; emi...@redhat.com; Elliott, Robert (Server Storage); scame...@beardog.cce.hp.com; h...@infradead.org Subject: Re: scsi error handling thread and REQUEST SENSE On Mon, 2014-05-19 at 10:32 +0200, Hannes Reinecke wrote: On 05/16/2014 10:05 PM, Ewan Milne wrote: On Fri, 2014-05-16 at 19:02 +, Elliott, Robert (Server Storage) wrote: There is an issue with a command timeout followed by a failed abort in the linux SCSI stack. This might explain some odd crashes I've seen, where it looks like a command might have completed *long* after it should have timed out. I have a few questions, see below: After triggering a timeout on a command like: [ 5454.196861] sd 2:0:0:1: [sds] Done: TIMEOUT [ 5454.196863] sd 2:0:0:1: [sds] Result: hostbyte=DID_OK driverbyte=DRIVER_OK [ 5454.196866] sd 2:0:0:1: [sds] CDB: Mode Sense(10): 5a 00 03 00 00 00 00 00 04 00 scsi_times_out() invokes scsi_abort_command(): [ 5454.196880] sd 2:0:0:1: [sds] scmd 880428963a70 abort scheduled and scmd_eh_abort_handler() tries to abort the command: [ 5454.206828] sd 2:0:0:1: [sds] aborting command 880428963a70 If the abort fails (with return value FAILED (0x2003 == 8195)): [ 5454.206832] sd 2:0:0:1: [sds] scmd 880428963a70 abort failed, rtn 8195 then scmd_eh_abort_handler() just gives up and expects the error handler thread to deal with the problem. When that thread (scsi_error_handler()) wakes up later on, it finds this command (and others) outstanding: [ 5454.373581] scsi_eh_2: waking up 0/3/3 [ 5454.375037] sd 2:0:0:1: scsi_eh_prt_fail_stats: cmds failed: 1, cancel: 0 [ 5454.377332] sd 2:0:0:11: scsi_eh_prt_fail_stats: cmds failed: 2, cancel: 0 [ 5454.379779] Total of 3 commands on 2 devices require eh work For each command, it starts with this check: #define SCSI_SENSE_VALID(scmd) \ (((scmd)-sense_buffer[0] 0x70) == 0x70) if ((scmd-eh_eflags SCSI_EH_CANCEL_CMD) || SCSI_SENSE_VALID(scmd)) continue; In this case, that if statement fails. The eflags bit is not set, and the sense data buffer still contains zeros or garbage - the command is still outstanding, so the buffer might be written at any time. (the sense buffer shouldn't be read unless a valid bit says it's filled in, and this lacks support for descriptor format sense data (type 0x72), but those are side issues) Doesn't the check for: (byte[0] 0x70) == 0x70 cover 0x70 - 0x73? Yes, I didn't read that closely enough. That means it also covers 0x74 to 0x7F, though, which are reserved and should not be interpreted as having any particular meaning. Strangely, the error handler code (scsi_unjam_host()) proceeds to send a REQUEST SENSE command and sees the resulting sense key of NO SENSE: [ 5454.381659] sd 2:0:0:1: [sds] scsi_eh_2: requesting sense [ 5454.383597] scsi_eh_done scmd: 880428963a70 result: 0 [ 5454.385457] sd 2:0:0:1: [sds] Done: UNKNOWN [ 5454.387430] sd 2:0:0:1: [sds] Result: hostbyte=DID_OK driverbyte=DRIVER_OK [ 5454.390450] sd 2:0:0:1: [sds] CDB: Request Sense: 03 00 00 00 60 00 [ 5454.393497] scsi_send_eh_cmnd: scmd: 880428963a70, timeleft: 9998 [ 5454.395667] scsi_send_eh_cmnd: scsi_eh_completed_normally 2002 [ 5454.397842] sense requested for 880428963a70 result 0 [ 5454.399675] sd 2:0:0:1: [sds] Sense Key : No Sense [current] [ 5454.402570] sd 2:0:0:1: [sds] Add. Sense: No additional sense information So, a command timed out, the abort didn't succeed, but a REQUEST SENSE completed normally? What kernel was this? Did it have the change to issue the abort in the timeout handler rather than the EH thread? It seems like it does, based on your description above. However, I'm wondering because I have seen crashes on kernels both with and without that change. This is with Christoph's scsi-mq-wip.7, which is based on Jens' block/for-next, which is based on 3.15-rc1. In that version, scsi_times_out() does this: if (host-transportt-eh_timed_out) rtn = host-transportt-eh_timed_out(scmd); else if (host-hostt-eh_timed_out) rtn = host-hostt-eh_timed_out(scmd); if (rtn == BLK_EH_NOT_HANDLED !host-hostt-no_async_abort) if (scsi_abort_command(scmd) == SUCCESS) return BLK_EH_NOT_HANDLED; In this case, there are no transport or LLD eh_timed_out() functions; scsi_abort_command() is called and returns FAILED. The bogus UNKNOWN print is being fixed by Hannes' logging patch. It just means the REQUEST SENSE command was submitted successfully. This
Re: dangling pointers and/or reentrancy in scmd_eh_abort_handler?
On Mon, May 19, 2014 at 05:08:56PM +0200, Bart Van Assche wrote: On 05/19/14 16:08, Paolo Bonzini wrote: 2) reentrancy: the softirq handler and scmd_eh_abort_handler can run concurrently, and call scsi_finish_command without any lock protecting the calls. You can then get memory corruption. I'm not sure what the recommended approach is to address this race. But it is possible to address this in the LLD. See e.g. the srp_claim_req() function in the SRP LLD and how it is invoked from the reply handler, the abort handler and the reset handlers in that LLD. blk-mq triest to solve this a test_and_set_bit for a completion flag at the block layer for completions vs timeouts. I think doing this in the SCSI layer as well would be very useful as we can't expect Joe Random Driver Developer to get it right in every driver. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dangling pointers and/or reentrancy in scmd_eh_abort_handler?
Il 19/05/2014 17:08, Bart Van Assche ha scritto: On 05/19/14 16:08, Paolo Bonzini wrote: 2) reentrancy: the softirq handler and scmd_eh_abort_handler can run concurrently, and call scsi_finish_command without any lock protecting the calls. You can then get memory corruption. I'm not sure what the recommended approach is to address this race. But it is possible to address this in the LLD. See e.g. the srp_claim_req() function in the SRP LLD and how it is invoked from the reply handler, the abort handler and the reset handlers in that LLD. That's not enough, unless I'm missing something. Say the request handler claims the request and the abort handler doesn't: - the request handler calls scsi_done and ends up in scsi_finish_command. - the abort handler will return SUCCESS, and scmd_eh_abort_handler then calls scsi_finish_command. Paolo -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/13 v2] [SCSI] qla2xxx: make return of 0 explicit
Hi Julia,
Status is already set to 0 at the beginning of the function, I think
we should just return status here to be consistent with the rest of
the function.
==
diff --git a/drivers/scsi/qla2xxx/qla_init.c
b/drivers/scsi/qla2xxx/qla_init.c
index 76af6b6..e339833 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -4587,7 +4587,6 @@ qla2x00_abort_isp(scsi_qla_host_t *vha)
if (unlikely(pci_channel_offline(ha-pdev)
ha-flags.pci_channel_io_perm_failure)) {
clear_bit(ISP_ABORT_RETRY, vha-dpc_flags);
- status = 0;
return status;
}
=
Thanks,
~Saurav
From: Julia Lawall julia.law...@lip6.fr
Delete unnecessary use of a local variable to immediately return 0.
A simplified version of the semantic patch that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@r exists@
local idexpression ret;
expression e;
position p;
@@
-ret = 0;
... when != ret = e
return
- ret
+ 0
;
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
Changed subject line, which was not appreciated by some spam filters.
drivers/scsi/qla2xxx/qla_init.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_init.c
b/drivers/scsi/qla2xxx/qla_init.c
index 38aeb54..a63f9b6 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -4593,8 +4593,7 @@ qla2x00_abort_isp(scsi_qla_host_t *vha)
if (unlikely(pci_channel_offline(ha-pdev)
ha-flags.pci_channel_io_perm_failure)) {
clear_bit(ISP_ABORT_RETRY, vha-dpc_flags);
- status = 0;
- return status;
+ return 0;
}
ha-isp_ops-get_flash_version(vha, req-ring);
attachment: winmail.dat
Re: dangling pointers and/or reentrancy in scmd_eh_abort_handler?
On 05/19/14 18:09, Paolo Bonzini wrote: Il 19/05/2014 17:08, Bart Van Assche ha scritto: On 05/19/14 16:08, Paolo Bonzini wrote: 2) reentrancy: the softirq handler and scmd_eh_abort_handler can run concurrently, and call scsi_finish_command without any lock protecting the calls. You can then get memory corruption. I'm not sure what the recommended approach is to address this race. But it is possible to address this in the LLD. See e.g. the srp_claim_req() function in the SRP LLD and how it is invoked from the reply handler, the abort handler and the reset handlers in that LLD. That's not enough, unless I'm missing something. Say the request handler claims the request and the abort handler doesn't: - the request handler calls scsi_done and ends up in scsi_finish_command. - the abort handler will return SUCCESS, and scmd_eh_abort_handler then calls scsi_finish_command. It depends on how the SCSI abort handler gets invoked. If the SCSI abort handler gets invoked because a SCSI command timed out that means that the block layer has already detected a timeout and also that the REQ_ATOM_COMPLETE bit has already been set. In this scenario if a SCSI LLD invokes scsi_done() that causes blk_complete_request() to return without invoking __blk_complete_request() and hence without invoking scsi_softirq_done(). Bart. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bnx2i: Make boot_nic entry visible in the sysfs session objects
FYI, this was part of the boot_nic sysfs patch which would allow iscsid to sync_session with info from the iBFT for iSCSI BFS via offload. This looks good to me. Acked-by: Eddie Wai eddie@broadcom.com On Mon, 2014-05-19 at 07:32 -0400, vikas.chaudh...@qlogic.com wrote: From: Tej Parkash tej.park...@qlogic.com Signed-off-by: Tej Parkash tej.park...@qlogic.com Signed-off-by: Vikas Chaudhary vikas.chaudh...@qlogic.com --- drivers/scsi/bnx2i/bnx2i_iscsi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c b/drivers/scsi/bnx2i/bnx2i_iscsi.c index 166543f..cabc8c1 100644 --- a/drivers/scsi/bnx2i/bnx2i_iscsi.c +++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c @@ -2234,6 +2234,9 @@ static umode_t bnx2i_attr_is_visible(int param_type, int param) case ISCSI_PARAM_TGT_RESET_TMO: case ISCSI_PARAM_IFACE_NAME: case ISCSI_PARAM_INITIATOR_NAME: + case ISCSI_PARAM_BOOT_ROOT: + case ISCSI_PARAM_BOOT_NIC: + case ISCSI_PARAM_BOOT_TARGET: return S_IRUGO; default: return 0; -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] hpsa driver updates May 8, 2014
The whole series looks good to me, Reviewed-by: Christoph Hellwig h...@lst.de -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [PATCH] drivers: scsi: mvsas: fix compiling issue by adding 'MVS_' for enum pci_interrupt_cause
Looks good to me, Reviewed-by: Christoph Hellwig h...@lst.de -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] lpfc 10.2.8001.0: Removed obsolete PCI IDs from the driver
On Mon, May 12, 2014 at 11:53:27AM -0400, James Smart wrote: Removed obsolete PCI IDs from the driver. How are these obsolete? -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] wd719x: Introduce Western Digital WD7193/7197/7296 PCI SCSI card driver
On Tue, Apr 01, 2014 at 11:03:00PM +0200, Ondrej Zary wrote: Introduce wd719x, a driver for Western Digital WD7193, WD7197 and WD7296 PCI SCSI controllers based on WD33C296A chip. Tested with WD7193 card. Signed-off-by: Ondrej Zary li...@rainbow-software.org Looks good to me, Reviewed-by: Christoph Hellwig h...@lst.de -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] lpfc 10.2.8001.0: Removed obsolete PCI IDs from the driver
:) for those distros, that want to pull only upstream'd patches, and where customers expect someone to take phone calls on any hardware recognized by the distro... the patch is to remove the hardware Emulex/the distro won't answer any questions for anymore. true - the hardware, if you can find it lying around somewhere, may still function. It won't get firmware updates, nor any mindshare. I'm not sure where the policy is for upstream - is it truly once known, can never be taken away ? -- james s On 5/19/2014 1:19 PM, Christoph Hellwig wrote: On Mon, May 12, 2014 at 11:53:27AM -0400, James Smart wrote: Removed obsolete PCI IDs from the driver. How are these obsolete? -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] virtio_scsi: use cmd_size
On Thu, 2014-05-01 at 16:51 +0200, Christoph Hellwig wrote:
Taken almost entirely from Nicholas Bellinger's scsi-mq conversion.
Signed-off-by: Christoph Hellwig h...@lst.de
Acked-by: Paolo Bonzini pbonz...@redhat.com
---
Reviewed-by: Nicholas Bellinger n...@linux-iscsi.org
drivers/scsi/virtio_scsi.c | 25 +++--
include/scsi/scsi_cmnd.h |9 +
2 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 16bfd50..5ec4a73 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -204,7 +204,6 @@ static void virtscsi_complete_cmd(struct virtio_scsi
*vscsi, void *buf)
set_driver_byte(sc, DRIVER_SENSE);
}
- mempool_free(cmd, virtscsi_cmd_pool);
sc-scsi_done(sc);
atomic_dec(tgt-reqs);
@@ -279,8 +278,6 @@ static void virtscsi_complete_free(struct virtio_scsi
*vscsi, void *buf)
if (cmd-comp)
complete_all(cmd-comp);
- else
- mempool_free(cmd, virtscsi_cmd_pool);
}
static void virtscsi_ctrl_done(struct virtqueue *vq)
@@ -496,10 +493,9 @@ static int virtscsi_queuecommand(struct virtio_scsi
*vscsi,
struct virtio_scsi_vq *req_vq,
struct scsi_cmnd *sc)
{
- struct virtio_scsi_cmd *cmd;
- int ret;
-
struct Scsi_Host *shost = virtio_scsi_host(vscsi-vdev);
+ struct virtio_scsi_cmd *cmd = scsi_cmd_priv(sc);
+
BUG_ON(scsi_sg_count(sc) shost-sg_tablesize);
/* TODO: check feature bit and fail if unsupported? */
@@ -508,11 +504,6 @@ static int virtscsi_queuecommand(struct virtio_scsi
*vscsi,
dev_dbg(sc-device-sdev_gendev,
cmd %p CDB: %#02x\n, sc, sc-cmnd[0]);
- ret = SCSI_MLQUEUE_HOST_BUSY;
- cmd = mempool_alloc(virtscsi_cmd_pool, GFP_ATOMIC);
- if (!cmd)
- goto out;
-
memset(cmd, 0, sizeof(*cmd));
cmd-sc = sc;
cmd-req.cmd = (struct virtio_scsi_cmd_req){
@@ -531,13 +522,9 @@ static int virtscsi_queuecommand(struct virtio_scsi
*vscsi,
if (virtscsi_kick_cmd(req_vq, cmd,
sizeof cmd-req.cmd, sizeof cmd-resp.cmd,
- GFP_ATOMIC) == 0)
- ret = 0;
- else
- mempool_free(cmd, virtscsi_cmd_pool);
-
-out:
- return ret;
+ GFP_ATOMIC) != 0)
+ return SCSI_MLQUEUE_HOST_BUSY;
+ return 0;
}
static int virtscsi_queuecommand_single(struct Scsi_Host *sh,
@@ -683,6 +670,7 @@ static struct scsi_host_template
virtscsi_host_template_single = {
.name = Virtio SCSI HBA,
.proc_name = virtio_scsi,
.this_id = -1,
+ .cmd_size = sizeof(struct virtio_scsi_cmd),
.queuecommand = virtscsi_queuecommand_single,
.eh_abort_handler = virtscsi_abort,
.eh_device_reset_handler = virtscsi_device_reset,
@@ -699,6 +687,7 @@ static struct scsi_host_template
virtscsi_host_template_multi = {
.name = Virtio SCSI HBA,
.proc_name = virtio_scsi,
.this_id = -1,
+ .cmd_size = sizeof(struct virtio_scsi_cmd),
.queuecommand = virtscsi_queuecommand_multi,
.eh_abort_handler = virtscsi_abort,
.eh_device_reset_handler = virtscsi_device_reset,
diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index dd7c998..e016e2a 100644
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
@@ -133,6 +133,15 @@ struct scsi_cmnd {
unsigned char tag; /* SCSI-II queued command tag */
};
+/*
+ * Return the driver private allocation behind the command.
+ * Only works if cmd_size is set in the host template.
+ */
+static inline void *scsi_cmd_priv(struct scsi_cmnd *cmd)
+{
+ return cmd + 1;
+}
+
/* make sure not to use it with REQ_TYPE_BLOCK_PC commands */
static inline struct scsi_driver *scsi_cmd_to_driver(struct scsi_cmnd *cmd)
{
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] scsi_debug: simple short transfer injection
On Thu, 2014-05-01 at 16:51 +0200, Christoph Hellwig wrote:
Add an option to only transfer half the data for every n-th command.
Signed-off-by: Christoph Hellwig h...@lst.de
Acked-by: Douglas Gilbert dgilb...@interlog.com
Reviewed-by: Nicholas Bellinger n...@linux-iscsi.org
---
drivers/scsi/scsi_debug.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index f3e9cc0..1328a26 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -130,6 +130,7 @@ static const char * scsi_debug_version_date = 20100324;
#define SCSI_DEBUG_OPT_DIF_ERR 32
#define SCSI_DEBUG_OPT_DIX_ERR 64
#define SCSI_DEBUG_OPT_MAC_TIMEOUT 128
+#define SCSI_DEBUG_OPT_SHORT_TRANSFER256
/* When every_nth 0 then modulo every_nth commands:
* - a no response is simulated if SCSI_DEBUG_OPT_TIMEOUT is set
* - a RECOVERED_ERROR is simulated on successful read and write
@@ -3583,6 +3584,7 @@ int scsi_debug_queuecommand_lck(struct scsi_cmnd
*SCpnt, done_funct_t done)
int inj_transport = 0;
int inj_dif = 0;
int inj_dix = 0;
+ int inj_short = 0;
int delay_override = 0;
int unmap = 0;
@@ -3628,6 +3630,8 @@ int scsi_debug_queuecommand_lck(struct scsi_cmnd
*SCpnt, done_funct_t done)
inj_dif = 1; /* to reads and writes below */
else if (SCSI_DEBUG_OPT_DIX_ERR scsi_debug_opts)
inj_dix = 1; /* to reads and writes below */
+ else if (SCSI_DEBUG_OPT_SHORT_TRANSFER scsi_debug_opts)
+ inj_short = 1;
}
if (devip-wlun) {
@@ -3744,6 +3748,10 @@ read:
if (scsi_debug_fake_rw)
break;
get_data_transfer_info(cmd, lba, num, ei_lba);
+
+ if (inj_short)
+ num /= 2;
+
errsts = resp_read(SCpnt, lba, num, devip, ei_lba);
if (inj_recovered (0 == errsts)) {
mk_sense_buffer(devip, RECOVERED_ERROR,
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] lpfc 10.2.8001.0: Removed obsolete PCI IDs from the driver
On Mon, May 19, 2014 at 01:39:50PM -0400, James Smart wrote: :) for those distros, that want to pull only upstream'd patches, and where customers expect someone to take phone calls on any hardware recognized by the distro... the patch is to remove the hardware Emulex/the distro won't answer any questions for anymore. true - the hardware, if you can find it lying around somewhere, may still function. It won't get firmware updates, nor any mindshare. I'm not sure where the policy is for upstream - is it truly once known, can never be taken away ? The policy is to leave it in even if unsupported, and let it it slowly bitrot. In some cases users will step up and maintain it, in most cases we will be able to recycle it after a few years. How about you stick in a printk that Emulex doesn't support the driver for these cards anymore? -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] virtio-scsi: Enable DIF/DIX modes in SCSI host LLD
On Wed, 2014-05-07 at 12:13 +0300, Michael S. Tsirkin wrote: On Mon, Apr 07, 2014 at 01:56:59AM -0700, Nicholas A. Bellinger wrote: On Mon, 2014-04-07 at 11:45 +0300, Michael S. Tsirkin wrote: On Sun, Apr 06, 2014 at 09:32:09PM +, Nicholas A. Bellinger wrote: From: Nicholas Bellinger n...@linux-iscsi.org This patch updates virtscsi_probe() to setup necessary Scsi_Host level protection resources. (currently hardcoded to 1) It changes virtscsi_add_cmd() to attach outgoing / incoming protection SGLs preceeding the data payload, and is using the new virtio_scsi_cmd_req_pi-d[oi],pi_niv field to signal to signal to vhost/scsi how many prot_sgs to expect. v3 changes: - Use VIRTIO_SCSI_F_T10_PI to determine PI or non PI header (Paolo) v2 changes: - Make protection buffer come before data buffer (Paolo) - Enable virtio_scsi_cmd_req_pi usage (Paolo) Cc: Paolo Bonzini pbonz...@redhat.com Cc: Michael S. Tsirkin m...@redhat.com Cc: Martin K. Petersen martin.peter...@oracle.com Cc: Christoph Hellwig h...@lst.de Cc: Hannes Reinecke h...@suse.de Cc: Sagi Grimberg sa...@dev.mellanox.co.il Cc: H. Peter Anvin h...@zytor.com Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org OK but we need to document the new interface in the spec (and incidentially, this will be useful to verify the assumptions made here and on the host side). Could you please submit this proposal to the OASIS Virtio TC for inclusion into the next spec draft? Ideally as a patch against the tex source, but a prose description would do as well. Most certainly. Please give me a bit to follow up on this, as the next couple of days are going to be hellishly busy.. Ping. We really need to get this moving to have the interface reviewed for the next merge window. Hi MST, So I've finally got some cycles to get back to this code, and wanted to verify the outstanding items you had previously raised: - Convert vhost-scsi to be independent of IOV layout using memcpy_fromiovecend. (Does this effect existing non PI virtio-scsi operation..?) - Report VIRTIO_F_ANY_LAYOUT feature bit to userspace. - Convert virtio_scsi_cmd_req_pi to bytes field instead of number of iovecs. - Ensure virtio_scsi_cmd_req_pi is naturally aligned - Figure out why QEMU is not acking (any) vhost-scsi feature bits Is there anything else that you'd like to see for an initial merge, or other issues that need to be addressed with the above..? --nab -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] virtio-scsi: Enable DIF/DIX modes in SCSI host LLD
On Mon, May 19, 2014 at 12:07:03PM -0700, Nicholas A. Bellinger wrote: On Wed, 2014-05-07 at 12:13 +0300, Michael S. Tsirkin wrote: On Mon, Apr 07, 2014 at 01:56:59AM -0700, Nicholas A. Bellinger wrote: On Mon, 2014-04-07 at 11:45 +0300, Michael S. Tsirkin wrote: On Sun, Apr 06, 2014 at 09:32:09PM +, Nicholas A. Bellinger wrote: From: Nicholas Bellinger n...@linux-iscsi.org This patch updates virtscsi_probe() to setup necessary Scsi_Host level protection resources. (currently hardcoded to 1) It changes virtscsi_add_cmd() to attach outgoing / incoming protection SGLs preceeding the data payload, and is using the new virtio_scsi_cmd_req_pi-d[oi],pi_niv field to signal to signal to vhost/scsi how many prot_sgs to expect. v3 changes: - Use VIRTIO_SCSI_F_T10_PI to determine PI or non PI header (Paolo) v2 changes: - Make protection buffer come before data buffer (Paolo) - Enable virtio_scsi_cmd_req_pi usage (Paolo) Cc: Paolo Bonzini pbonz...@redhat.com Cc: Michael S. Tsirkin m...@redhat.com Cc: Martin K. Petersen martin.peter...@oracle.com Cc: Christoph Hellwig h...@lst.de Cc: Hannes Reinecke h...@suse.de Cc: Sagi Grimberg sa...@dev.mellanox.co.il Cc: H. Peter Anvin h...@zytor.com Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org OK but we need to document the new interface in the spec (and incidentially, this will be useful to verify the assumptions made here and on the host side). Could you please submit this proposal to the OASIS Virtio TC for inclusion into the next spec draft? Ideally as a patch against the tex source, but a prose description would do as well. Most certainly. Please give me a bit to follow up on this, as the next couple of days are going to be hellishly busy.. Ping. We really need to get this moving to have the interface reviewed for the next merge window. Hi MST, So I've finally got some cycles to get back to this code, and wanted to verify the outstanding items you had previously raised: - Convert vhost-scsi to be independent of IOV layout using memcpy_fromiovecend. (Does this effect existing non PI virtio-scsi operation..?) Ideally yes. - Report VIRTIO_F_ANY_LAYOUT feature bit to userspace. - Convert virtio_scsi_cmd_req_pi to bytes field instead of number of iovecs. - Ensure virtio_scsi_cmd_req_pi is naturally aligned It turns out other virtio scsi commands aren't aligned? If true we don't need to make an exception here. - Figure out why QEMU is not acking (any) vhost-scsi feature bits Is there anything else that you'd like to see for an initial merge, or other issues that need to be addressed with the above..? --nab FYI Paolo sent a spec patch for the feature. Have you seen it? -- MST -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/13 v2] [SCSI] qla2xxx: make return of 0 explicit
On Mon, May 19, 2014 at 04:07:52PM +, Saurav Kashyap wrote: Hi Julia, Status is already set to 0 at the beginning of the function, I think we should just return status here to be consistent with the rest of the function. return 0; is more clear than return status;. Consistency is great so long as it makes the code easier to read. Don't lose track of the real goal. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] virtio-scsi: Enable DIF/DIX modes in SCSI host LLD
On Mon, 2014-05-19 at 22:15 +0300, Michael S. Tsirkin wrote: On Mon, May 19, 2014 at 12:07:03PM -0700, Nicholas A. Bellinger wrote: On Wed, 2014-05-07 at 12:13 +0300, Michael S. Tsirkin wrote: On Mon, Apr 07, 2014 at 01:56:59AM -0700, Nicholas A. Bellinger wrote: On Mon, 2014-04-07 at 11:45 +0300, Michael S. Tsirkin wrote: On Sun, Apr 06, 2014 at 09:32:09PM +, Nicholas A. Bellinger wrote: From: Nicholas Bellinger n...@linux-iscsi.org This patch updates virtscsi_probe() to setup necessary Scsi_Host level protection resources. (currently hardcoded to 1) It changes virtscsi_add_cmd() to attach outgoing / incoming protection SGLs preceeding the data payload, and is using the new virtio_scsi_cmd_req_pi-d[oi],pi_niv field to signal to signal to vhost/scsi how many prot_sgs to expect. v3 changes: - Use VIRTIO_SCSI_F_T10_PI to determine PI or non PI header (Paolo) v2 changes: - Make protection buffer come before data buffer (Paolo) - Enable virtio_scsi_cmd_req_pi usage (Paolo) Cc: Paolo Bonzini pbonz...@redhat.com Cc: Michael S. Tsirkin m...@redhat.com Cc: Martin K. Petersen martin.peter...@oracle.com Cc: Christoph Hellwig h...@lst.de Cc: Hannes Reinecke h...@suse.de Cc: Sagi Grimberg sa...@dev.mellanox.co.il Cc: H. Peter Anvin h...@zytor.com Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org OK but we need to document the new interface in the spec (and incidentially, this will be useful to verify the assumptions made here and on the host side). Could you please submit this proposal to the OASIS Virtio TC for inclusion into the next spec draft? Ideally as a patch against the tex source, but a prose description would do as well. Most certainly. Please give me a bit to follow up on this, as the next couple of days are going to be hellishly busy.. Ping. We really need to get this moving to have the interface reviewed for the next merge window. Hi MST, So I've finally got some cycles to get back to this code, and wanted to verify the outstanding items you had previously raised: - Convert vhost-scsi to be independent of IOV layout using memcpy_fromiovecend. (Does this effect existing non PI virtio-scsi operation..?) Ideally yes. Er, so changing vhost-scsi to be independent of IOV layout will have the side effect of breaking existing non PI virtio-scsi logic..? - Report VIRTIO_F_ANY_LAYOUT feature bit to userspace. - Convert virtio_scsi_cmd_req_pi to bytes field instead of number of iovecs. - Ensure virtio_scsi_cmd_req_pi is naturally aligned It turns out other virtio scsi commands aren't aligned? Correct, virtio_scsi_cmd_req is currently 51 bytes. If true we don't need to make an exception here. nod - Figure out why QEMU is not acking (any) vhost-scsi feature bits Is there anything else that you'd like to see for an initial merge, or other issues that need to be addressed with the above..? --nab FYI Paolo sent a spec patch for the feature. Have you seen it? Yep, looks fine. --nab -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] lpfc: Use time_after()
To be future-proof and for better readability the time comparisons are modified
to use time_after() instead of plain, error-prone math.
Signed-off-by: Manuel Schölling manuel.schoell...@gmx.de
---
drivers/scsi/lpfc/lpfc_scsi.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c
index 462453e..fb5351a 100644
--- a/drivers/scsi/lpfc/lpfc_scsi.c
+++ b/drivers/scsi/lpfc/lpfc_scsi.c
@@ -380,12 +380,14 @@ lpfc_rampdown_queue_depth(struct lpfc_hba *phba)
{
unsigned long flags;
uint32_t evt_posted;
+ unsigned long expires;
spin_lock_irqsave(phba-hbalock, flags);
atomic_inc(phba-num_rsrc_err);
phba-last_rsrc_error_time = jiffies;
- if ((phba-last_ramp_down_time + QUEUE_RAMP_DOWN_INTERVAL) jiffies) {
+ expires = phba-last_ramp_down_time + QUEUE_RAMP_DOWN_INTERVAL;
+ if (time_after(expires, jiffies)) {
spin_unlock_irqrestore(phba-hbalock, flags);
return;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] virtio-scsi: Enable DIF/DIX modes in SCSI host LLD
On Mon, May 19, 2014 at 01:54:50PM -0700, Nicholas A. Bellinger wrote: On Mon, 2014-05-19 at 22:15 +0300, Michael S. Tsirkin wrote: On Mon, May 19, 2014 at 12:07:03PM -0700, Nicholas A. Bellinger wrote: On Wed, 2014-05-07 at 12:13 +0300, Michael S. Tsirkin wrote: On Mon, Apr 07, 2014 at 01:56:59AM -0700, Nicholas A. Bellinger wrote: On Mon, 2014-04-07 at 11:45 +0300, Michael S. Tsirkin wrote: On Sun, Apr 06, 2014 at 09:32:09PM +, Nicholas A. Bellinger wrote: From: Nicholas Bellinger n...@linux-iscsi.org This patch updates virtscsi_probe() to setup necessary Scsi_Host level protection resources. (currently hardcoded to 1) It changes virtscsi_add_cmd() to attach outgoing / incoming protection SGLs preceeding the data payload, and is using the new virtio_scsi_cmd_req_pi-d[oi],pi_niv field to signal to signal to vhost/scsi how many prot_sgs to expect. v3 changes: - Use VIRTIO_SCSI_F_T10_PI to determine PI or non PI header (Paolo) v2 changes: - Make protection buffer come before data buffer (Paolo) - Enable virtio_scsi_cmd_req_pi usage (Paolo) Cc: Paolo Bonzini pbonz...@redhat.com Cc: Michael S. Tsirkin m...@redhat.com Cc: Martin K. Petersen martin.peter...@oracle.com Cc: Christoph Hellwig h...@lst.de Cc: Hannes Reinecke h...@suse.de Cc: Sagi Grimberg sa...@dev.mellanox.co.il Cc: H. Peter Anvin h...@zytor.com Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org OK but we need to document the new interface in the spec (and incidentially, this will be useful to verify the assumptions made here and on the host side). Could you please submit this proposal to the OASIS Virtio TC for inclusion into the next spec draft? Ideally as a patch against the tex source, but a prose description would do as well. Most certainly. Please give me a bit to follow up on this, as the next couple of days are going to be hellishly busy.. Ping. We really need to get this moving to have the interface reviewed for the next merge window. Hi MST, So I've finally got some cycles to get back to this code, and wanted to verify the outstanding items you had previously raised: - Convert vhost-scsi to be independent of IOV layout using memcpy_fromiovecend. (Does this effect existing non PI virtio-scsi operation..?) Ideally yes. Er, so changing vhost-scsi to be independent of IOV layout will have the side effect of breaking existing non PI virtio-scsi logic..? Sorry I didn't make myself clear. I merely think that all code should do memcpy_fromiovecend etc. If done peoperly guests will not notice unless they test VIRTIO_F_ANY_LAYOUT. - Report VIRTIO_F_ANY_LAYOUT feature bit to userspace. - Convert virtio_scsi_cmd_req_pi to bytes field instead of number of iovecs. - Ensure virtio_scsi_cmd_req_pi is naturally aligned It turns out other virtio scsi commands aren't aligned? Correct, virtio_scsi_cmd_req is currently 51 bytes. If true we don't need to make an exception here. nod - Figure out why QEMU is not acking (any) vhost-scsi feature bits Is there anything else that you'd like to see for an initial merge, or other issues that need to be addressed with the above..? --nab FYI Paolo sent a spec patch for the feature. Have you seen it? Yep, looks fine. --nab -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/13 v2] [SCSI] qla2xxx: make return of 0 explicit
On Mon, 19 May 2014, Dan Carpenter wrote: On Mon, May 19, 2014 at 04:07:52PM +, Saurav Kashyap wrote: Hi Julia, Status is already set to 0 at the beginning of the function, I think we should just return status here to be consistent with the rest of the function. return 0; is more clear than return status;. Consistency is great so long as it makes the code easier to read. Don't lose track of the real goal. If status were an informative word, there might be a reason for it. But integer typed functions almost always return their status, so there is no real information. julia -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/13 v2] [SCSI] qla2xxx: make return of 0 explicit
On Tue, May 20, 2014 at 07:36:48AM +0800, Julia Lawall wrote: On Mon, 19 May 2014, Dan Carpenter wrote: On Mon, May 19, 2014 at 04:07:52PM +, Saurav Kashyap wrote: Hi Julia, Status is already set to 0 at the beginning of the function, I think we should just return status here to be consistent with the rest of the function. return 0; is more clear than return status;. Consistency is great so long as it makes the code easier to read. Don't lose track of the real goal. If status were an informative word, there might be a reason for it. But integer typed functions almost always return their status, so there is no real information. Just to be clear, I'm agreeing with you... return 0; is better. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] scsi patch queue tree
Hi Christoph, On Mon, 19 May 2014 07:06:14 -0700 Christoph Hellwig h...@infradead.org wrote: I'd like to announce the new scsi patch queue tree, which will pick up any scsi core or driver patches promptly to allow easy integration and feedback that contributors might be used to from other kernel subsystems. There are two branches, one for the SCSI core and upper level drivers, and one for low-level (hardware) drivers: git://git.infradead.org/users/hch/scsi-queue.git core-for-3.16 git://git.infradead.org/users/hch/scsi-queue.git drivers-for-3.16 The rules for the tree are: - it has at least two positive reviews (non-author signoff, reviewed-by or acked-by tags). In practice this means it had at least one and I added another one. - no negative review on the mailing list - it applies cleanly - it compiles cleanly (drivers for architectures I can't test excluded) - for core the core branch: survives a full xfstests run I went through the linux-scsi archives for March, April and May and applied all patches that clearly fit the above criteria, but it's fairly like I missed some. If I'm missing your patch(es): - resend it unless it was sent in the last few weeks - make sure all reviews are recorded in the most recent post of the patch(es) - ping the list for additional reviewers For now the prime intent of the tree is to feed it to James, although I'd welcome everyone interested to pull and test it. If the scheme proves successful I'd love to invite more core scsi contributors to help with it and move to a shared kernel.org tree. Is this a request for inclusion of those branches into linux-next separately from the scsi tree itself? -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH v2] [PATCH] drivers: scsi: mvsas: fix compiling issue by adding 'MVS_' for enum pci_interrupt_cause
On 05/20/2014 01:18 AM, Christoph Hellwig wrote: Looks good to me, Reviewed-by: Christoph Hellwig h...@lst.de OK, thanks. And I shall continue, and should finish allmodconfig for unicore32 within this month (which I already delayed one month more). Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 76241] USB Device Not Recognised
https://bugzilla.kernel.org/show_bug.cgi?id=76241 --- Comment #3 from zhouqi zhouqikevi...@gmail.com --- (In reply to Alan from comment #2) 2.6.27 is obsolete. Sorry，Not obsolete for my program I need to reopen it -- You are receiving this mail because: You are the assignee for the bug.-- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 76241] USB Device Not Recognised
https://bugzilla.kernel.org/show_bug.cgi?id=76241 zhouqi zhouqikevi...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|OBSOLETE|--- -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] virtio_scsi: don't call virtqueue_add_sgs(... GFP_NOIO) holding spinlock.
This triggers every time we do a SCSI abort:
virtscsi_tmf - virtscsi_kick_cmd (grab lock and call) - virtscsi_add_cmd
- virtqueue_add_sgs (GFP_NOIO)
Logs look like this:
sd 0:0:0:0: [sda] abort
BUG: sleeping function called from invalid context at mm/slub.c:966
in_atomic(): 1, irqs_disabled(): 1, pid: 6, name: kworker/u2:0
3 locks held by kworker/u2:0/6:
#0: (scsi_tmf_%dshost-host_no){..}, at: [c0153180]
process_one_work+0xe0/0x3d0
#1: (((cmd-abort_work)-work)){..}, at: [c0153180]
process_one_work+0xe0/0x3d0
#2: ((virtscsi_vq-vq_lock)-rlock){..}, at: [c043f508]
virtscsi_kick_cmd+0x18/0x1b0
CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.15.0-rc5+ #110
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.7.5-rc1-0-gb1d4dc9-20140515_140003-nilsson.home.kraxel.org 04/01/2014
Workqueue: scsi_tmf_0 scmd_eh_abort_handler
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index db3b494e5926..62757afd93bb 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -433,11 +433,10 @@ static void virtscsi_event_done(struct virtqueue *vq)
* @cmd: command structure
* @req_size : size of the request buffer
* @resp_size : size of the response buffer
- * @gfp: flags to use for memory allocations
*/
static int virtscsi_add_cmd(struct virtqueue *vq,
struct virtio_scsi_cmd *cmd,
- size_t req_size, size_t resp_size, gfp_t gfp)
+ size_t req_size, size_t resp_size)
{
struct scsi_cmnd *sc = cmd-sc;
struct scatterlist *sgs[4], req, resp;
@@ -469,19 +468,19 @@ static int virtscsi_add_cmd(struct virtqueue *vq,
if (in)
sgs[out_num + in_num++] = in-sgl;
- return virtqueue_add_sgs(vq, sgs, out_num, in_num, cmd, gfp);
+ return virtqueue_add_sgs(vq, sgs, out_num, in_num, cmd, GFP_ATOMIC);
}
static int virtscsi_kick_cmd(struct virtio_scsi_vq *vq,
struct virtio_scsi_cmd *cmd,
-size_t req_size, size_t resp_size, gfp_t gfp)
+size_t req_size, size_t resp_size)
{
unsigned long flags;
int err;
bool needs_kick = false;
spin_lock_irqsave(vq-vq_lock, flags);
- err = virtscsi_add_cmd(vq-vq, cmd, req_size, resp_size, gfp);
+ err = virtscsi_add_cmd(vq-vq, cmd, req_size, resp_size);
if (!err)
needs_kick = virtqueue_kick_prepare(vq-vq);
@@ -530,8 +529,7 @@ static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
memcpy(cmd-req.cmd.cdb, sc-cmnd, sc-cmd_len);
if (virtscsi_kick_cmd(req_vq, cmd,
- sizeof cmd-req.cmd, sizeof cmd-resp.cmd,
- GFP_ATOMIC) == 0)
+ sizeof cmd-req.cmd, sizeof cmd-resp.cmd) == 0)
ret = 0;
else
mempool_free(cmd, virtscsi_cmd_pool);
@@ -596,8 +594,7 @@ static int virtscsi_tmf(struct virtio_scsi *vscsi, struct
virtio_scsi_cmd *cmd)
cmd-comp = comp;
if (virtscsi_kick_cmd(vscsi-ctrl_vq, cmd,
- sizeof cmd-req.tmf, sizeof cmd-resp.tmf,
- GFP_NOIO) 0)
+ sizeof cmd-req.tmf, sizeof cmd-resp.tmf) 0)
goto out;
wait_for_completion(comp);
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] scsi patch queue tree
On Tue, May 20, 2014 at 10:03:43AM +1000, Stephen Rothwell wrote: Is this a request for inclusion of those branches into linux-next separately from the scsi tree itself? James said he wants to include it in the scsi tree, but given how late we are in the cycle I'd love to see separate exposure until that happens on a temporary basis. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
