Re: [PATCH v2 0/8] qla2xxx: Updates for Target Mode driver
On Tue, 2015-07-14 at 16:00 -0400, Himanshu Madhani wrote: > Hi James, > > This series is applied on top of patch series sent on June 10 >[PATCH 0/9] qla2xxx: Patches for scsi "misc" branch > (http://marc.info/?l=linux-scsi&m=143395156920505&w=2) > > These set of patches addresses issue with reuse of stale command found > in a customer enviorment. Here's sequence of events which could result > into this reuse of stale command which could potentially lead to data > corruption. > - Backend driver goes out of sync with front end driver due to session > management problem. > - During this time a session receives a NEW login by the same initiator. > - All the commands from previous session are not flushed before establishing > a new session/connection. > - These stale commands leaks into new session resulting into case > where they could potentially share same Exchange ID. > In such case data can cross path between old and new session when the frontend > driver/fabric driver allows a new connection to be established without backend > knowledge. To fix this problem, old session is destroyed first before creating > new session. The session destroy process would wait for all existing commands > to finish. > > The Changes from v1 of this series are: > > - Rebased patch series on top of v4.2.0-rc1+. > - Dropped following patches and will be sent as seperate series. > qla2xxx: Added interface to send ELS commands from driver. > qla2xxx: delete session if initiator is gone from FW > qla2xxx: wait for all conflicts before ack'ing PLOGI > > Please apply these patches to scsi tree at your earliest for inclusion in the > next mainline merge window. > > Thanks, > Himanshu > > Alexei Potashnik (6): > qla2xxx: delay plogi/prli ack until existing sessions are deleted > qla2xxx: Abort stale cmds on qla_tgt_wq when plogi arrives > qla2xxx: added sess generations to detect RSCN update races > qla2xxx: disable scsi_transport_fc registration in target mode > qla2xxx: drop cmds/tmrs arrived while session is being deleted > qla2xxx: terminate exchange when command is aborted by LIO > > Roland Dreier (1): > qla2xxx: kill sessions/log out initiator on RSCN and port down events > > Swapnil Nagle (1): > qla2xxx: cleanup cmd in qla workqueue before processing TMR > > drivers/scsi/qla2xxx/qla_dbg.c |6 +- > drivers/scsi/qla2xxx/qla_def.h | 12 + > drivers/scsi/qla2xxx/qla_init.c| 188 -- > drivers/scsi/qla2xxx/qla_iocb.c|3 + > drivers/scsi/qla2xxx/qla_os.c | 11 +- > drivers/scsi/qla2xxx/qla_target.c | 714 > +--- > drivers/scsi/qla2xxx/qla_target.h | 69 +++- > drivers/scsi/qla2xxx/tcm_qla2xxx.c | 23 +- > 8 files changed, 906 insertions(+), 120 deletions(-) > Thanks for re-submitting the patches that only address outstanding qla2xxx target mode bugs. Normally I would be apprehensive about merging this for v4.2-rc code, given the size of the changes involved.. However, the changes are localized to qla2xxx target, are submitted by the hardware LLD maintainer(s), contributed by an serious customer of the code, and are all marked for CC' stable. Given these circumstances, it doesn't make sense to wait another 6 weeks to get these real-world bug-fixes into mainline. That said, I'm applying this series to target-pending/master now, and will be planning to include in the v4.2-rc fixes PULL request to Linus sometime next week. Please let me know if the series has issues, and should not be merged up. As mentioned in the previous email, also please let me know which patches in the series preceding this one need to be marked for stable too, as they will be a stable dependency for this series. Thank you QLogic + Pure Storage folks. --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] target: fix crash in cmd tracing when cmd didn't match a LUN
On Thu, Jul 23, 2015 at 03:19:32PM -0700, Spencer Baugh wrote: > From: Alexei Potashnik > > If command didn't match a LUN and we're sending check condition, the > target_cmd_complete ftrace point will crash because it assumes that > cmd->t_task_cdb has been set. > > The fix will temporarily set t_task_cdb to the se_cmd buffer > and copy first 6 bytes of cdb in there as soon as possible. > At a later point t_task_cdb is reset to the correct buffer, > but until then traces and printks don't cause a crash. This is too ugly to live. Just dropping the t_task_cdb dereference from the trace point sounds like the simples quick fix for now, and removing the crazy layering violation in iSCSI that opencode target_submit_cmd is the proper long term fix. -- 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 101891] mvsas prep failed, NULL pointer dereference in mvs_slot_task_free+0x5/0x1f0 [mvsas]
https://bugzilla.kernel.org/show_bug.cgi?id=101891 --- Comment #2 from Dāvis --- (In reply to Dāvis from comment #0) > Got this call trace, it caused any attempts to access those disks hang > (couldn't even kill those processes, eg. ls). > Using HighPoint RocketRAID 2760A controller. > > kernel: mvsas :07:00.0: mvsas prep failed[0]! > kernel: sas: Enter sas_scsi_recover_host busy: 1 failed: 1 > kernel: sas: trying to find task 0x880213ac6a00 > kernel: sas: sas_scsi_find_task: aborting task 0x880213ac6a00 > kernel: BUG: unable to handle kernel NULL pointer dereference at > 0010 > kernel: IP: [] mvs_slot_task_free+0x5/0x1f0 [mvsas] > kernel: PGD 1ee973067 PUD 1ee974067 PMD 0 > kernel: Oops: [#1] PREEMPT SMP > kernel: Modules linked in: fuse nf_conntrack_netbios_ns > nf_conntrack_broadcast xt_tcpudp ip6t_rpfilter ip > kernel: aesni_intel rc_core snd_hda_codec_realtek aes_x86_64 lrw gf128mul > videobuf2_dma_sg glue_helper a > kernel: CPU: 3 PID: 227 Comm: scsi_eh_7 Tainted: P O > 4.1.2-2-ARCH #1 > kernel: Hardware name: Gigabyte Technology Co., Ltd. > GA-990FXA-UD3/GA-990FXA-UD3, BIOS FFe 11/08/2013 > kernel: task: 88007f849e90 ti: 880223184000 task.ti: 880223184000 > kernel: RIP: 0010:[] [] > mvs_slot_task_free+0x5/0x1f0 [mvsas] > kernel: RSP: 0018:880223187d00 EFLAGS: 00010a13 > kernel: RAX: 2e8ba2e8ba2e8ba3 RBX: 880213ac6a00 RCX: a2e8bb8b9cb3907b > kernel: RDX: RSI: 880213ac6a00 RDI: 88022244 > kernel: RBP: 880223187d58 R08: 000a R09: 0607 > kernel: R10: 000213fc R11: 0607 R12: 0005 > kernel: R13: 880222a59000 R14: 88022244 R15: 880213ac6a08 > kernel: FS: 7fdddc839880() GS:88022ecc() > knlGS: > kernel: CS: 0010 DS: ES: CR0: 8005003b > kernel: CR2: 0010 CR3: 0001ee978000 CR4: 000407e0 > kernel: Stack: > kernel: a0210bde 88020018 880223187d68 880223187d28 > kernel: a5257e12 88007f840208 0005 880223187db0 > kernel: 880213ac6a08 8802230ef000 880213ac6a00 880223187e28 > kernel: Call Trace: > kernel: [] ? mvs_abort_task+0x1ce/0x230 [mvsas] > kernel: [] sas_scsi_recover_host+0x47b/0xc20 [libsas] > kernel: [] scsi_error_handler+0xfc/0x580 [scsi_mod] > kernel: [] ? __schedule+0x362/0xa30 > kernel: [] ? scsi_eh_get_sense+0x190/0x190 [scsi_mod] > kernel: [] kthread+0xd8/0xf0 > kernel: [] ? kthread_worker_fn+0x170/0x170 > kernel: [] ret_from_fork+0x42/0x70 > kernel: [] ? kthread_worker_fn+0x170/0x170 > kernel: Code: 84 00 00 00 00 00 66 66 66 66 90 55 48 8b 87 b0 00 00 00 89 f6 > 48 89 e5 f0 48 0f b3 30 5d c > kernel: RIP [] mvs_slot_task_free+0x5/0x1f0 [mvsas] > kernel: RSP > kernel: CR2: 0010 > kernel: ---[ end trace 18b7a6f928680374 ]--- It didn't used to happen before, but now today got it again. Seems it's quite reproducible as my usage was pretty similar, basically heavy I/O, rsync and compiling. Also seems there's no way to get disks back but just reboot as removing kernel modules fail (not even with force). -- You are receiving this mail because: You are watching the assignee of 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: [PATCH 1/5] scsi: rescan VPD attributes
On Wed, Jul 08, 2015 at 01:09:44PM +0200, Hannes Reinecke wrote:
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
> @@ -264,8 +264,11 @@ static int alua_check_vpd(struct scsi_device *sdev,
> struct alua_dh_data *h)
> int device_id_size, device_id_type = 0;
> struct alua_port_group *tmp_pg, *pg = NULL;
>
> - if (!sdev->vpd_pg83)
> + rcu_read_lock();
> + if (!rcu_dereference(sdev->vpd_pg83)) {
> + rcu_read_unlock();
> return SCSI_DH_DEV_UNSUPP;
> + }
>
> /*
>* Look for the correct descriptor.
> @@ -281,8 +284,8 @@ static int alua_check_vpd(struct scsi_device *sdev,
> struct alua_dh_data *h)
>*/
> memset(device_id_str, 0, 256);
> device_id_size = 0;
> - d = sdev->vpd_pg83 + 4;
> - while (d < sdev->vpd_pg83 + sdev->vpd_pg83_len) {
> + d = rcu_dereference(sdev->vpd_pg83) + 4;
> + while (d < rcu_dereference(sdev->vpd_pg83) + sdev->vpd_pg83_len) {
Seem like this code would benefit from a local variable in favor of the
repeated rcu_dereference() calls.
> @@ -803,7 +803,7 @@ void scsi_attach_vpd(struct scsi_device *sdev)
I think this function could use a new name, e.g. scsi_read_vpd_pages?
> @@ -563,8 +563,9 @@ static void ses_match_to_enclosure(struct
> enclosure_device *edev,
> if (!sdev->vpd_pg83_len)
> return;
>
> - desc = sdev->vpd_pg83 + 4;
> - while (desc < sdev->vpd_pg83 + sdev->vpd_pg83_len) {
> + rcu_read_lock();
> + desc = rcu_dereference(sdev->vpd_pg83) + 4;
> + while (desc < rcu_dereference(sdev->vpd_pg83) + sdev->vpd_pg83_len) {
A local variable or two would help here as well.
--
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/5] scsi: rescan VPD attributes
On 07/24/2015 04:38 PM, Christoph Hellwig wrote:
> On Wed, Jul 08, 2015 at 01:09:44PM +0200, Hannes Reinecke wrote:
>> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
>> @@ -264,8 +264,11 @@ static int alua_check_vpd(struct scsi_device *sdev,
>> struct alua_dh_data *h)
>> int device_id_size, device_id_type = 0;
>> struct alua_port_group *tmp_pg, *pg = NULL;
>>
>> -if (!sdev->vpd_pg83)
>> +rcu_read_lock();
>> +if (!rcu_dereference(sdev->vpd_pg83)) {
>> +rcu_read_unlock();
>> return SCSI_DH_DEV_UNSUPP;
>> +}
>>
>> /*
>> * Look for the correct descriptor.
>> @@ -281,8 +284,8 @@ static int alua_check_vpd(struct scsi_device *sdev,
>> struct alua_dh_data *h)
>> */
>> memset(device_id_str, 0, 256);
>> device_id_size = 0;
>> -d = sdev->vpd_pg83 + 4;
>> -while (d < sdev->vpd_pg83 + sdev->vpd_pg83_len) {
>> +d = rcu_dereference(sdev->vpd_pg83) + 4;
>> +while (d < rcu_dereference(sdev->vpd_pg83) + sdev->vpd_pg83_len) {
>
> Seem like this code would benefit from a local variable in favor of the
> repeated rcu_dereference() calls.
>
Yeah, possibly. After all, the variable isn't expected to change
under rcu_read_lock().
>> @@ -803,7 +803,7 @@ void scsi_attach_vpd(struct scsi_device *sdev)
>
> I think this function could use a new name, e.g. scsi_read_vpd_pages?
>
>> @@ -563,8 +563,9 @@ static void ses_match_to_enclosure(struct
>> enclosure_device *edev,
>> if (!sdev->vpd_pg83_len)
>> return;
>>
>> -desc = sdev->vpd_pg83 + 4;
>> -while (desc < sdev->vpd_pg83 + sdev->vpd_pg83_len) {
>> +rcu_read_lock();
>> +desc = rcu_dereference(sdev->vpd_pg83) + 4;
>> +while (desc < rcu_dereference(sdev->vpd_pg83) + sdev->vpd_pg83_len) {
>
> A local variable or two would help here as well.
>
Okay.
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (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: [PATCH 1/5] scsi: rescan VPD attributes
On Fri, Jul 24, 2015 at 04:40:42PM +0200, Hannes Reinecke wrote: > Yeah, possibly. After all, the variable isn't expected to change > under rcu_read_lock(). Actually it can and will change, that's the point. But if you use a local variable you keep a single version of it, which won't be freed until after rcu_read_unlock. -- 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 4/5] scsi_dh_alua: add 'state' callback function
As per the comment on patch 3 I'd rather expose the ALUA state in the core SCSI code. But having this alua_state attribute in core SCSI code sounds fine to me. -- 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 04/20] scsi_dh_alua: Improve error handling
This seems to be a bit of a catchall. Can you split the logging changes from actual error code logic changes and describe the latter in more detail? -- 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 07/20] scsi_dh_alua: Pass buffer as function argument
> - rq->cmd[6] = (h->bufflen >> 24) & 0xff; > - rq->cmd[7] = (h->bufflen >> 16) & 0xff; > - rq->cmd[8] = (h->bufflen >> 8) & 0xff; > - rq->cmd[9] = h->bufflen & 0xff; > + put_unaligned_be32(bufflen, &rq->cmd[6]); This is unrelated to the rest of the patch, can you split it out, maybe together with other get/put_unaligned conversions? Otherwise looks good: Reviewed-by: Christoph Hellwig -- 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 08/20] scsi_dh_alua: Make stpg synchronous
> - memset(h->buff, 0, stpg_len); > - h->buff[4] = TPGS_STATE_OPTIMIZED & 0x0f; > - h->buff[6] = (h->group_id >> 8) & 0xff; > - h->buff[7] = h->group_id & 0xff; > + memset(stpg_data, 0, stpg_len); > + stpg_data[4] = TPGS_STATE_OPTIMIZED & 0x0f; > + put_unaligned_be16(group_id, &stpg_data[6]); Unrelated get/put_unaligned changes again. > - if (!scsi_normalize_sense(h->sense, SCSI_SENSE_BUFFERSIZE, > + if (!(driver_byte(retval) & DRIVER_SENSE) || > + !scsi_normalize_sense(h->sense, SCSI_SENSE_BUFFERSIZE, Where does this come from? > + (!h->pref) && no need for braces here. -- 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 0/9] qla2xxx: Patches for scsi "misc" branch.
On Thu, 2015-07-23 at 23:38 -0700, Nicholas A. Bellinger wrote: > Hi Himanshu & Co, > > (Adding target-devel CC') > > On Wed, 2015-06-10 at 11:05 -0400, Himanshu Madhani wrote: > > Hi James, > > > > Please apply the following patches to the scsi tree at your earliest > > convenience for inclusion in the next mainline merge window. > > > > Thanks, > > Himanshu > > > > Himanshu Madhani (3): > > qla2xxx: Enable target mode for ISP27XX > > qla2xxx: Remove msleep in qlt_send_term_exchange > > qla2xxx: Enable Target counters in DebugFS. > > > > Kanoj Sarcar (1): > > qla2xxx: fix command initialization in target mode. > > > > Quinn Tran (4): > > qla2xxx: Add flush after updating ATIOQ consumer index. > > qla2xxx: release request queue reservation. > > qla2xxx: adjust debug flags > > qla2xxx: Add FW resource count in DebugFS. > > > > Saurav Kashyap (1): > > qla2xxx: Fix hardware lock/unlock issue causing kernel panic. > > > > drivers/scsi/qla2xxx/qla_attr.c|2 +- > > drivers/scsi/qla2xxx/qla_def.h | 36 ++--- > > drivers/scsi/qla2xxx/qla_dfs.c | 106 > > > > drivers/scsi/qla2xxx/qla_gbl.h |3 +- > > drivers/scsi/qla2xxx/qla_init.c| 20 --- > > drivers/scsi/qla2xxx/qla_iocb.c|1 + > > drivers/scsi/qla2xxx/qla_mbx.c | 31 +-- > > drivers/scsi/qla2xxx/qla_os.c |1 + > > drivers/scsi/qla2xxx/qla_sup.c |2 +- > > drivers/scsi/qla2xxx/qla_target.c | 60 - > > drivers/scsi/qla2xxx/qla_target.h |3 + > > drivers/scsi/qla2xxx/tcm_qla2xxx.c |9 ++- > > 12 files changed, 208 insertions(+), 66 deletions(-) > > > > This series contains a number of qla2xxx target mode related bug-fixes > that have not made it into scsi.git after 6 weeks on the list. I don't > see a good reason to wait another 6 weeks for v4.3-rc1 to get these into > mainline. According to the request, they're not fixes, they're targetted for the merge window. As such, they still require reviews ... but if you'd like to provide them, that would be great. > That said, I'm going to merge patches #1-#7 via target-pending/master > now and submit for v4.2-rc code. Please re-submit the non bug-fix > related changes in patches #8-#9 as for-4.3 code to JEJB -> scsi.git. I don't, in principle object to this demand, because it looks for the description that the bug fixes should be split out, except that you should follow proper process and have one independent review. Hannes or Christoph are probably the best placed. James > Here's the updated diff-stat for the bug-fix series. > > Himanshu Madhani (2): > qla2xxx: Enable target mode for ISP27XX > qla2xxx: Remove msleep in qlt_send_term_exchange > > Kanoj Sarcar (1): > qla2xxx: fix command initialization in target mode. > > Quinn Tran (3): > qla2xxx: Add flush after updating ATIOQ consumer index. > qla2xxx: release request queue reservation. > qla2xxx: adjust debug flags > > Saurav Kashyap (1): > qla2xxx: Fix hardware lock/unlock issue causing kernel panic. > > drivers/scsi/qla2xxx/qla_attr.c| 2 +- > drivers/scsi/qla2xxx/qla_def.h | 8 +++ > drivers/scsi/qla2xxx/qla_init.c| 8 +-- > drivers/scsi/qla2xxx/qla_mbx.c | 7 +++--- > drivers/scsi/qla2xxx/qla_os.c | 1 + > drivers/scsi/qla2xxx/qla_sup.c | 2 +- > drivers/scsi/qla2xxx/qla_target.c | 49 > +++--- > drivers/scsi/qla2xxx/qla_target.h | 3 +++ > drivers/scsi/qla2xxx/tcm_qla2xxx.c | 3 +-- > 9 files changed, 46 insertions(+), 37 deletions(-) > > -- > 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 > -- 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 09/20] scsi_dh_alua: switch to scsi_execute()
Seems like this should use scsi_execute_req_flags instead so that it doesn't have to deal with the raw sense buffer. -- 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 11/20] scsi_dh_alua: Use separate alua_port_group structure
On Wed, Jul 08, 2015 at 11:06:09AM +0200, Hannes Reinecke wrote:
> + pg = kzalloc(sizeof(struct alua_port_group), GFP_KERNEL);
> + if (!pg) {
> + sdev_printk(KERN_WARNING, sdev,
> + "%s: kzalloc port group failed\n",
> + ALUA_DH_NAME);
> + /* Temporary failure, bypass */
> + return SCSI_DH_DEV_TEMP_BUSY;
> + }
> + pg->group_id = group_id;
> + pg->buff = pg->inq;
> + pg->bufflen = ALUA_INQUIRY_SIZE;
> + pg->tpgs = h->tpgs;
> + pg->state = TPGS_STATE_OPTIMIZED;
> + kref_init(&pg->kref);
> + spin_lock(&port_group_lock);
> + list_add(&pg->node, &port_group_list);
> + h->pg = pg;
> + spin_unlock(&port_group_lock);
Is there any high level protection against someone racing to allocate
this structure, e.g. from a sysfs-initiated scan?
> - len = (h->buff[0] << 24) + (h->buff[1] << 16) +
> - (h->buff[2] << 8) + h->buff[3] + 4;
> + len = get_unaligned_be32(&pg->buff[0]) + 4;
Andother spurious get/set_unaligned conversion. I'd really recommend doing
all of them before the atual series.
> + rcu_read_lock();
> + pg = rcu_dereference(h->pg);
> + if (!pg) {
> + rcu_read_unlock();
> + return -ENXIO;
> + }
> + rcu_read_unlock();
> +
> if (optimize)
> - h->flags |= ALUA_OPTIMIZE_STPG;
> + pg->flags |= ALUA_OPTIMIZE_STPG;
> else
> - h->flags &= ~ALUA_OPTIMIZE_STPG;
> + pg->flags |= ~ALUA_OPTIMIZE_STPG;
You'll need to move the rcu_read_unlock here to be safe.
--
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 12/20] scsi_dh_alua: allocate RTPG buffer separately
Looks good, Reviewed-by: Christoph Hellwig -- 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 13/20] scsi_dh_alua: simplify sense code handling
> + /* > + * Retry on ALUA state transition or if any > + * UNIT ATTENTION occurred. > + */ > + if (sense_hdr.sense_key == NOT_READY && > + sense_hdr.asc == 0x04 && sense_hdr.ascq == 0x0a) > + err = SCSI_DH_RETRY; > + if (sense_hdr.sense_key == UNIT_ATTENTION) else if or just but cases in the same condition for clarity? Otherwise looks fine: Reviewed-by: Christoph Hellwig -- 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 14/20] scsi_dh_alua: parse target device id
On Wed, Jul 08, 2015 at 11:06:12AM +0200, Hannes Reinecke wrote: > Parse VPD descriptor to figure out the device identification. > As devices might implement several descriptors the order > of preference is: > - NAA IEE Registered Extended > - EUI-64 based 16-byte > - EUI-64 based 12-byte > - NAA IEEE Registered > - NAA IEEE Extended > A SCSI name string descriptor is preferred to all of them > if the identification is longer than 16 bytes. Can you move this to scsi_mod.ko? I'll need the same code for the NFS SCSI layout driver soon. -- 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] USB: storage: add "no SYNCHRONIZE CACHE" quirk
On Mon, 22 Jun 2015, James Bottomley wrote: > On Mon, 2015-06-22 at 13:48 -0400, Alan Stern wrote: > > On Mon, 22 Jun 2015, James Bottomley wrote: > > > > > On Mon, 2015-06-22 at 13:30 -0400, Alan Stern wrote: > > > > On Mon, 22 Jun 2015, James Bottomley wrote: > > > > > > > > > I'm not sure I entirely like this: we are back again treating data > > > > > corruption problems silently. > > > > > > > > > > However, I also believe treating a single flush failure as a critical > > > > > filesystem error is also wrong: The data's all there correctly; all > > > > > it > > > > > does is introduce a potential window were the FS could get corrupted > > > > > in > > > > > the unlikely event the system crashed. > > > > > > > > > > Obviously, for a disk with a writeback cache that can't do flush, that > > > > > window is much wider and the real solution should be to try to switch > > > > > the cache to write through. > > > > > > > > I agree. Doing the switch manually (by writing to the "cache_type" > > > > attribute file) works, but it's a nuisance to do this when you have a > > > > portable USB drive that gets moved among a bunch of machines. > > > > > > Perhaps it might be wise to do this to every USB device ... for external > > > devices, the small performance gain doesn't really make up for the > > > potential data loss. > > > > > > > > How about something like this patch? It transforms FS FLUSH into a > > > > > log > > > > > warning from an error but preserves the error on any other path. > > > > > You'll > > > > > still get a fairly continuous dump of warnings for one of these > > > > > devices, > > > > > though ... do they respond to mode selects turning off the writeback? > > > > > > > > I would be very surprised if any of those drives support MODE SELECT at > > > > all. > > > > > > I assume the cache type attribute file you refer to above is just > > > pretending their cache is write through rather than actually setting it > > > to be so? > > > > Yes; I'm referring to cache_type_store() in sd.c, and writing > > "temporary write through", which does not issue a MODE SELECT command. > > It would be easy enough for people to try leaving out the "temporary", > > but I don't expect it to work. > > > > > The original IDE device had no way of turning their cache > > > types to write through either, but the manufacturers were eventually > > > convinced of the error of their ways. > > > > In this case the stupidity resides in the USB-ATA bridge. You can see > > the gory details at > > > > https://bugzilla.kernel.org/show_bug.cgi?id=89511#c19 > > OK, so that says the SAT in the bridge doesn't know what to do with > MODE_SELECT (probably unsurprising given that it's a usb bridge). the > SATA disk should respond to the ATA command SET FEATURES, though. > Presuming we can get it through the bridge. > > You can try it with > > hdparm -W 0 > > optionally with --prefer_ata_12 to do the 12 instead of 16 byte > encapsulation and see if that makes a difference. Dan Williams recently posted the content below to the Bugzilla report: > I have a drive with this problem and I tested 4.0.8 with this hunk > added to the patch above. > > UNUSUAL_DEV( 0x0bc2, 0x0888, 0x, 0x, > "Seagate", > "USB 2.0 Pocket Hard Drive", > USB_SC_DEVICE, USB_PR_DEVICE, NULL, > US_FL_NO_SYNCHRONIZE_CACHE), > > I don't have the linux-usb thread around so I can reply to > http://www.spinics.net/lists/linux-usb/msg126364.html, but here's the > result of: > > [dcbw@localhost ~]$ sudo hdparm -W 0 --prefer-ata12 /dev/sdb > > /dev/sdb: > setting drive write-caching to 0 (off) > SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 > 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 In English: "Illegal Request: Invalid command operation code". Apparently there's no way to tell the drive to change its caching. > SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 > 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 > 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 > 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 > 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > write-caching = not supported > > What was the upstream resolution on this one? So far there isn't any. Alan Stern -- 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 16/20] scsi_dh_alua: Use workqueue for RTPG
> + charwork_q_name[264];
create_workqueue and friends now accept printf-like format
string, so there is no need for this temporary buffer.
> + int error;
> + struct completion init_complete;
Please rename error to init_error and only assign to it before calling
complete().
Also I'm not sure what the real point of init_complete is, shouldn't
we just have a mutex held in alua_initialize and alua_activate to
synchronize the two against each other?
> + rcu_read_lock();
> + pg = rcu_dereference(h->pg);
> + if (pg) {
> + kref_get(&pg->kref);
> + rcu_read_unlock();
> + alua_rtpg_queue(pg, sdev, NULL);
> + kref_put(&pg->kref, release_port_group);
> + } else
> + rcu_read_unlock();
> +}
How about:
rcu_read_lock();
pg = rcu_dereference(h->pg);
if (!pg) {
rcu_read_unlock();
return;
}
kref_get(&pg->kref);
rcu_read_unlock();
alua_rtpg_queue(pg, sdev, NULL);
kref_put(&pg->kref, release_port_group);
--
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 14/20] scsi_dh_alua: parse target device id
> "Christoph" == Christoph Hellwig writes: Christoph> Can you move this to scsi_mod.ko? I'll need the same code Christoph> for the NFS SCSI layout driver soon. Same here. Working on copy offload again. -- Martin K. Petersen Oracle Linux Engineering -- 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 0/9] qla2xxx: Patches for scsi "misc" branch.
Hi Nic, On 7/23/15, 11:45 PM, "Nicholas A. Bellinger" wrote: >On Thu, 2015-07-23 at 23:38 -0700, Nicholas A. Bellinger wrote: >> Hi Himanshu & Co, >> >> (Adding target-devel CC') >> >> On Wed, 2015-06-10 at 11:05 -0400, Himanshu Madhani wrote: >> > Hi James, > > > >> This series contains a number of qla2xxx target mode related bug-fixes >> that have not made it into scsi.git after 6 weeks on the list. I don't >> see a good reason to wait another 6 weeks for v4.3-rc1 to get these into >> mainline. >> >> That said, I'm going to merge patches #1-#7 via target-pending/master >> now and submit for v4.2-rc code. Please re-submit the non bug-fix >> related changes in patches #8-#9 as for-4.3 code to JEJB -> scsi.git. >> >> Here's the updated diff-stat for the bug-fix series. >> >> Himanshu Madhani (2): >> qla2xxx: Enable target mode for ISP27XX >> qla2xxx: Remove msleep in qlt_send_term_exchange >> >> Kanoj Sarcar (1): >> qla2xxx: fix command initialization in target mode. >> >> Quinn Tran (3): >> qla2xxx: Add flush after updating ATIOQ consumer index. >> qla2xxx: release request queue reservation. >> qla2xxx: adjust debug flags >> >> Saurav Kashyap (1): >> qla2xxx: Fix hardware lock/unlock issue causing kernel panic. >> >> drivers/scsi/qla2xxx/qla_attr.c| 2 +- >> drivers/scsi/qla2xxx/qla_def.h | 8 +++ >> drivers/scsi/qla2xxx/qla_init.c| 8 +-- >> drivers/scsi/qla2xxx/qla_mbx.c | 7 +++--- >> drivers/scsi/qla2xxx/qla_os.c | 1 + >> drivers/scsi/qla2xxx/qla_sup.c | 2 +- >> drivers/scsi/qla2xxx/qla_target.c | 49 >>+++--- >> drivers/scsi/qla2xxx/qla_target.h | 3 +++ >> drivers/scsi/qla2xxx/tcm_qla2xxx.c | 3 +-- >> 9 files changed, 46 insertions(+), 37 deletions(-) >> > >Which reminds me, some of bug-fixes need proper CC' stable tags. > >Can you give me your best guess as to which patches these should be, and >the approximate versions for the stable team to pick up..? This patch http://marc.info/?l=linux-scsi&m=143395154920491&w=2 is already marked for stable and should be included in 3.18 and onwards. In addition following patches should be picked up by stable team for 3.18 and onwards. http://marc.info/?l=linux-scsi&m=143395156620504&w=2 http://marc.info/?l=linux-scsi&m=143395156320500&w=2 http://marc.info/?l=linux-scsi&m=143395154820489&w=2 > >Thank you, > >--nab > <>
Re: [PATCH 0/9] qla2xxx: Patches for scsi "misc" branch.
Hi Nic, James, On 7/24/15, 7:51 AM, "James Bottomley" wrote: >On Thu, 2015-07-23 at 23:38 -0700, Nicholas A. Bellinger wrote: >> Hi Himanshu & Co, >> >> (Adding target-devel CC') >> >> On Wed, 2015-06-10 at 11:05 -0400, Himanshu Madhani wrote: >> > Hi James, >> > >> > Please apply the following patches to the scsi tree at your earliest >> > convenience for inclusion in the next mainline merge window. >> > >> > Thanks, >> > Himanshu >> > >> > Himanshu Madhani (3): >> > qla2xxx: Enable target mode for ISP27XX >> > qla2xxx: Remove msleep in qlt_send_term_exchange >> > qla2xxx: Enable Target counters in DebugFS. >> > >> > Kanoj Sarcar (1): >> > qla2xxx: fix command initialization in target mode. >> > >> > Quinn Tran (4): >> > qla2xxx: Add flush after updating ATIOQ consumer index. >> > qla2xxx: release request queue reservation. >> > qla2xxx: adjust debug flags >> > qla2xxx: Add FW resource count in DebugFS. >> > >> > Saurav Kashyap (1): >> > qla2xxx: Fix hardware lock/unlock issue causing kernel panic. >> > >> > drivers/scsi/qla2xxx/qla_attr.c|2 +- >> > drivers/scsi/qla2xxx/qla_def.h | 36 ++--- >> > drivers/scsi/qla2xxx/qla_dfs.c | 106 >> >> > drivers/scsi/qla2xxx/qla_gbl.h |3 +- >> > drivers/scsi/qla2xxx/qla_init.c| 20 --- >> > drivers/scsi/qla2xxx/qla_iocb.c|1 + >> > drivers/scsi/qla2xxx/qla_mbx.c | 31 +-- >> > drivers/scsi/qla2xxx/qla_os.c |1 + >> > drivers/scsi/qla2xxx/qla_sup.c |2 +- >> > drivers/scsi/qla2xxx/qla_target.c | 60 - >> > drivers/scsi/qla2xxx/qla_target.h |3 + >> > drivers/scsi/qla2xxx/tcm_qla2xxx.c |9 ++- >> > 12 files changed, 208 insertions(+), 66 deletions(-) >> > >> >> This series contains a number of qla2xxx target mode related bug-fixes >> that have not made it into scsi.git after 6 weeks on the list. I don't >> see a good reason to wait another 6 weeks for v4.3-rc1 to get these into >> mainline. > >According to the request, they're not fixes, they're targetted for the >merge window. As such, they still require reviews ... but if you'd like >to provide them, that would be great. > >> That said, I'm going to merge patches #1-#7 via target-pending/master >> now and submit for v4.2-rc code. Please re-submit the non bug-fix >> related changes in patches #8-#9 as for-4.3 code to JEJB -> scsi.git. > >I don't, in principle object to this demand, because it looks for the >description that the bug fixes should be split out, except that you >should follow proper process and have one independent review. Hannes or >Christoph are probably the best placed. I will resubmit patches #8-#9 in next submission. > >James > >> Here's the updated diff-stat for the bug-fix series. >> >> Himanshu Madhani (2): >> qla2xxx: Enable target mode for ISP27XX >> qla2xxx: Remove msleep in qlt_send_term_exchange >> >> Kanoj Sarcar (1): >> qla2xxx: fix command initialization in target mode. >> >> Quinn Tran (3): >> qla2xxx: Add flush after updating ATIOQ consumer index. >> qla2xxx: release request queue reservation. >> qla2xxx: adjust debug flags >> >> Saurav Kashyap (1): >> qla2xxx: Fix hardware lock/unlock issue causing kernel panic. >> >> drivers/scsi/qla2xxx/qla_attr.c| 2 +- >> drivers/scsi/qla2xxx/qla_def.h | 8 +++ >> drivers/scsi/qla2xxx/qla_init.c| 8 +-- >> drivers/scsi/qla2xxx/qla_mbx.c | 7 +++--- >> drivers/scsi/qla2xxx/qla_os.c | 1 + >> drivers/scsi/qla2xxx/qla_sup.c | 2 +- >> drivers/scsi/qla2xxx/qla_target.c | 49 >>+++--- >> drivers/scsi/qla2xxx/qla_target.h | 3 +++ >> drivers/scsi/qla2xxx/tcm_qla2xxx.c | 3 +-- >> 9 files changed, 46 insertions(+), 37 deletions(-) >> >> -- >> 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 >> > > > Thanks, Himanshu <>
Re: [PATCH v2 3/3] cxlflash: Virtual LUN support
On 07/16/2015 06:26 PM, Matthew R. Ochs wrote:
> +
> +/**
> + * ba_clone() - frees a block from the block allocator
> + * @ba_lun: Block allocator from which to allocate a block.
> + * @to_free: Block to free.
> + *
> + * Return: 0 on success, -1 on failure
> + */
> +static int ba_clone(struct ba_lun *ba_lun, u64 to_clone)
> +{
> + struct ba_lun_info *lun_info =
> + (struct ba_lun_info *)ba_lun->ba_lun_handle;
> +
> + if (validate_alloc(lun_info, to_clone)) {
> + pr_err("%s: AUN %llX is not allocated on lun_id %llX\n",
> +__func__, to_clone, ba_lun->lun_id);
Suggest using dev_err here instead to scope the error to the adapter.
> + return -1;
Might be nice to return a better error to the user in both of the error cases
in this code.
> + }
> +
> + pr_debug("%s: Received a request to clone AUN %llX on lun_id %llX\n",
> + __func__, to_clone, ba_lun->lun_id);
> +
> + if (lun_info->aun_clone_map[to_clone] == MAX_AUN_CLONE_CNT) {
> + pr_err("%s: AUN %llX on lun_id %llX hit max clones already\n",
> +__func__, to_clone, ba_lun->lun_id);
> + return -1;
> + }
> +
> + lun_info->aun_clone_map[to_clone]++;
> +
> + return 0;
> +}
> +
> +
> +/**
> + * init_ba() - initializes and allocates a block allocator
> + * @lun_info:LUN information structure that owns the block allocator.
> + *
> + * Return: 0 on success, -errno on failure
> + */
> +static int init_ba(struct llun_info *lli)
> +{
> + int rc = 0;
> + struct glun_info *gli = lli->parent;
> + struct blka *blka = &gli->blka;
> +
> + memset(blka, 0, sizeof(*blka));
> + mutex_init(&blka->mutex);
> +
> + /* LUN IDs are unique per port, save the index instead */
> + blka->ba_lun.lun_id = lli->lun_index;
> + blka->ba_lun.lsize = gli->max_lba + 1;
> + blka->ba_lun.lba_size = gli->blk_len;
> +
> + blka->ba_lun.au_size = MC_CHUNK_SIZE;
> + blka->nchunk = blka->ba_lun.lsize / MC_CHUNK_SIZE;
> +
> + rc = ba_init(&blka->ba_lun);
> + if (rc) {
> + pr_err("%s: cannot init block_alloc, rc=%d\n", __func__, rc);
> + goto init_ba_exit;
The goto here is unnecessary
> + }
> +
> +init_ba_exit:
> + pr_debug("%s: returning rc=%d lli=%p\n", __func__, rc, lli);
> + return rc;
> +}
> +
> +/**
> + * write_same16() - sends a SCSI WRITE_SAME16 (0) command to specified LUN
> + * @sdev:SCSI device associated with LUN.
> + * @lba: Logical block address to start write same.
> + * @nblks: Number of logical blocks to write same.
> + *
> + * Return: 0 on success, -1 on failure
> + */
> +static int write_same16(struct scsi_device *sdev,
> + u64 lba,
> + u32 nblks)
> +{
> + u8 scsi_cmd[MAX_COMMAND_SIZE];
> + u8 *cmd_buf = NULL;
> + u8 *sense_buf = NULL;
> + int rc = 0;
> + int result = 0;
> + int ws_limit = SISLITE_MAX_WS_BLOCKS;
> + u64 offset = lba;
> + int left = nblks;
> +
> + memset(scsi_cmd, 0, sizeof(scsi_cmd));
> + cmd_buf = kzalloc(CMD_BUFSIZE, GFP_KERNEL);
> + sense_buf = kzalloc(SCSI_SENSE_BUFFERSIZE, GFP_NOIO);
> + if (!cmd_buf || !sense_buf) {
> + rc = -ENOMEM;
> + goto out;
> + }
> +
> + while (left > 0) {
> +
> + scsi_cmd[0] = WRITE_SAME_16;
> + put_unaligned_be64(offset, &scsi_cmd[2]);
> + put_unaligned_be32(ws_limit < left ? ws_limit : left,
> +&scsi_cmd[10]);
> +
> + left -= ws_limit;
> + offset += ws_limit;
> +
> + result = scsi_execute(sdev, scsi_cmd, DMA_TO_DEVICE, cmd_buf,
> + CMD_BUFSIZE, sense_buf,
> + (MC_DISCOVERY_TIMEOUT*HZ), 5, 0, NULL);
5 seconds seems a little on the short side for this command. Perhaps using
sdev->request_queue->rq_timeout would be better?
> +
> + if (result) {
> + pr_err("%s: command failed for offset %lld"
> + " result=0x%x\n", __func__, offset, result);
> + rc = -EIO;
> + goto out;
> + }
> + }
> +
> +out:
You need to free cmd_buf and sense_buf here.
> + pr_debug("%s: returning rc=%d\n", __func__, rc);
> + return rc;
> +}
> +
> +
> +/**
> + * _cxlflash_vlun_resize() - changes the size of a virtual lun
> + * @sdev:SCSI device associated with LUN owning virtual LUN.
> + * @ctxi:Context owning resources.
> + * @resize: Resize ioctl data structure.
> + *
> + * On successful return, the user is informed of the new size (in blocks)
> + * of the virtual lun in last LBA format. When the size of the virtual
> + * lun is zero, the last LBA is reflected as -1.
> + *
> + * Return: 0 on success, -errno on failure
> + */
> +int _cxlflash_vlun_resize(struct scsi_device *sdev,
> +
Re: [PATCH] target: fix crash in cmd tracing when cmd didn't match a LUN
On Fri, 2015-07-24 at 12:52 +0200, Christoph Hellwig wrote: > On Thu, Jul 23, 2015 at 03:19:32PM -0700, Spencer Baugh wrote: > > From: Alexei Potashnik > > > > If command didn't match a LUN and we're sending check condition, the > > target_cmd_complete ftrace point will crash because it assumes that > > cmd->t_task_cdb has been set. > > > > The fix will temporarily set t_task_cdb to the se_cmd buffer > > and copy first 6 bytes of cdb in there as soon as possible. > > At a later point t_task_cdb is reset to the correct buffer, > > but until then traces and printks don't cause a crash. > > This is too ugly to live. Just dropping the t_task_cdb dereference > from the trace point sounds like the simples quick fix for now, Yes, that is what I'd prefer as well. > and removing the crazy layering violation in iSCSI that opencode > target_submit_cmd is the proper long term fix. We've already been through this discussion a couple of years back when target_submit_cmd() first came into existence. The reason iscsi/iser-target continues to be a special case is due to immediate data vs. non immediate data and their respective command sequence number ordering requirements. --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 0/9] qla2xxx: Patches for scsi "misc" branch.
On Fri, 2015-07-24 at 07:51 -0700, James Bottomley wrote: > On Thu, 2015-07-23 at 23:38 -0700, Nicholas A. Bellinger wrote: > > Hi Himanshu & Co, > > > > (Adding target-devel CC') > > > > On Wed, 2015-06-10 at 11:05 -0400, Himanshu Madhani wrote: > > > Hi James, > > > > > > Please apply the following patches to the scsi tree at your earliest > > > convenience for inclusion in the next mainline merge window. > > > > > > Thanks, > > > Himanshu > > > > > > Himanshu Madhani (3): > > > qla2xxx: Enable target mode for ISP27XX > > > qla2xxx: Remove msleep in qlt_send_term_exchange > > > qla2xxx: Enable Target counters in DebugFS. > > > > > > Kanoj Sarcar (1): > > > qla2xxx: fix command initialization in target mode. > > > > > > Quinn Tran (4): > > > qla2xxx: Add flush after updating ATIOQ consumer index. > > > qla2xxx: release request queue reservation. > > > qla2xxx: adjust debug flags > > > qla2xxx: Add FW resource count in DebugFS. > > > > > > Saurav Kashyap (1): > > > qla2xxx: Fix hardware lock/unlock issue causing kernel panic. > > > > > > drivers/scsi/qla2xxx/qla_attr.c|2 +- > > > drivers/scsi/qla2xxx/qla_def.h | 36 ++--- > > > drivers/scsi/qla2xxx/qla_dfs.c | 106 > > > > > > drivers/scsi/qla2xxx/qla_gbl.h |3 +- > > > drivers/scsi/qla2xxx/qla_init.c| 20 --- > > > drivers/scsi/qla2xxx/qla_iocb.c|1 + > > > drivers/scsi/qla2xxx/qla_mbx.c | 31 +-- > > > drivers/scsi/qla2xxx/qla_os.c |1 + > > > drivers/scsi/qla2xxx/qla_sup.c |2 +- > > > drivers/scsi/qla2xxx/qla_target.c | 60 - > > > drivers/scsi/qla2xxx/qla_target.h |3 + > > > drivers/scsi/qla2xxx/tcm_qla2xxx.c |9 ++- > > > 12 files changed, 208 insertions(+), 66 deletions(-) > > > > > > > This series contains a number of qla2xxx target mode related bug-fixes > > that have not made it into scsi.git after 6 weeks on the list. I don't > > see a good reason to wait another 6 weeks for v4.3-rc1 to get these into > > mainline. > > According to the request, they're not fixes, they're targetted for the > merge window. As such, they still require reviews ... but if you'd like > to provide them, that would be great. > Yes, I've reviewed + signed-off-by on the patches #1-#7 that are now in target-pending/master. > > That said, I'm going to merge patches #1-#7 via target-pending/master > > now and submit for v4.2-rc code. Please re-submit the non bug-fix > > related changes in patches #8-#9 as for-4.3 code to JEJB -> scsi.git. > > I don't, in principle object to this demand, because it looks for the > description that the bug fixes should be split out, except that you > should follow proper process and have one independent review. Hannes or > Christoph are probably the best placed. > Each of the patches merged has two signed-off-by from different QLogic folks, along with my own signed-off-by. -- 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 0/9] qla2xxx: Patches for scsi "misc" branch.
On Fri, 2015-07-24 at 18:32 +, Himanshu Madhani wrote: > Hi Nic, > > > On 7/23/15, 11:45 PM, "Nicholas A. Bellinger" wrote: > > >On Thu, 2015-07-23 at 23:38 -0700, Nicholas A. Bellinger wrote: > >> Hi Himanshu & Co, > >> > >> (Adding target-devel CC') > >> > >> On Wed, 2015-06-10 at 11:05 -0400, Himanshu Madhani wrote: > >> > Hi James, > > > > > > > >> This series contains a number of qla2xxx target mode related bug-fixes > >> that have not made it into scsi.git after 6 weeks on the list. I don't > >> see a good reason to wait another 6 weeks for v4.3-rc1 to get these into > >> mainline. > >> > >> That said, I'm going to merge patches #1-#7 via target-pending/master > >> now and submit for v4.2-rc code. Please re-submit the non bug-fix > >> related changes in patches #8-#9 as for-4.3 code to JEJB -> scsi.git. > >> > >> Here's the updated diff-stat for the bug-fix series. > >> > >> Himanshu Madhani (2): > >> qla2xxx: Enable target mode for ISP27XX > >> qla2xxx: Remove msleep in qlt_send_term_exchange > >> > >> Kanoj Sarcar (1): > >> qla2xxx: fix command initialization in target mode. > >> > >> Quinn Tran (3): > >> qla2xxx: Add flush after updating ATIOQ consumer index. > >> qla2xxx: release request queue reservation. > >> qla2xxx: adjust debug flags > >> > >> Saurav Kashyap (1): > >> qla2xxx: Fix hardware lock/unlock issue causing kernel panic. > >> > >> drivers/scsi/qla2xxx/qla_attr.c| 2 +- > >> drivers/scsi/qla2xxx/qla_def.h | 8 +++ > >> drivers/scsi/qla2xxx/qla_init.c| 8 +-- > >> drivers/scsi/qla2xxx/qla_mbx.c | 7 +++--- > >> drivers/scsi/qla2xxx/qla_os.c | 1 + > >> drivers/scsi/qla2xxx/qla_sup.c | 2 +- > >> drivers/scsi/qla2xxx/qla_target.c | 49 > >>+++--- > >> drivers/scsi/qla2xxx/qla_target.h | 3 +++ > >> drivers/scsi/qla2xxx/tcm_qla2xxx.c | 3 +-- > >> 9 files changed, 46 insertions(+), 37 deletions(-) > >> > > > >Which reminds me, some of bug-fixes need proper CC' stable tags. > > > >Can you give me your best guess as to which patches these should be, and > >the approximate versions for the stable team to pick up..? > > This patch http://marc.info/?l=linux-scsi&m=143395154920491&w=2 is already > marked for stable and should be included in 3.18 and onwards. In addition > following > patches should be picked up by stable team for 3.18 and onwards. > > http://marc.info/?l=linux-scsi&m=143395156620504&w=2 > > http://marc.info/?l=linux-scsi&m=143395156320500&w=2 > > http://marc.info/?l=linux-scsi&m=143395154820489&w=2 > The stable v3.18+ tags for patch #1, #4, #6, and #7 have been added to target-pending/master. Since this series is a dependency for the larger patch-set from the Pure folks, I'll go ahead and update those patches to a v3.18+ tag as well. Thank you, --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] qla2xxx: Return the fabric command state for non-task management requests
Which debug printk do you care about? I'd much prefer having a trace point inside the driver which could even pretty print it instead of the hack where a driver defined binary value is printed by the core. -- 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] target: add support for START_STOP_UNIT SCSI opcode
On Fri, Jul 24, 2015 at 03:06:12AM +, Elliott, Robert (Server Storage) wrote: > Note that the officially published versions of the ISO and ANSI > standards don't carry that revision number r36; they just have > the standard name and year. SBC-3 revision 36 became > "ANSI INCITS 514-2014 Information technology - SCSI Block > Commands - 3 (SBC-3)". > > T10 isn't really obligated to keep making particular working > drafts available, although the ones that have been assigned > version descriptors (in SPC-n) are more likely to stick > around. For SBC-3, only revisions 35 and 36 earned those. Unfortunately the final T10 standards are only available for a high monetary cost, so they aren't useful for Free Software development. We work arounds this by referencing specific drafts that are available. If T10 would regress even more by not providing them we'd have to find other work arounds. -- 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] target: fix crash in cmd tracing when cmd didn't match a LUN
On Fri, Jul 24, 2015 at 01:32:14PM -0700, Nicholas A. Bellinger wrote: > We've already been through this discussion a couple of years back when > target_submit_cmd() first came into existence. > > The reason iscsi/iser-target continues to be a special case is due to > immediate data vs. non immediate data and their respective command > sequence number ordering requirements. I don't see how immediate data plays into this, the write_pending callbacks can simply skip the data transfer path, similar to what Bart's port of the latest SRP target to lio does as well. -- 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
