This is a note to let you know that I've just added the patch titled
target: fix race during implicit transition work flushes
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
target-fix-race-during-implicit-transition-work-flushes.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:12:34 CET 2017
From: Mike Christie <mchristi(a)redhat.com>
Date: Thu, 2 Mar 2017 04:59:50 -0600
Subject: target: fix race during implicit transition work flushes
From: Mike Christie <mchristi(a)redhat.com>
[ Upstream commit 760bf578edf8122f2503a3a6a3f4b0de3b6ce0bb ]
This fixes the following races:
1. core_alua_do_transition_tg_pt could have read
tg_pt_gp_alua_access_state and gone into this if chunk:
if (!explicit &&
atomic_read(&tg_pt_gp->tg_pt_gp_alua_access_state) ==
ALUA_ACCESS_STATE_TRANSITION) {
and then core_alua_do_transition_tg_pt_work could update the
state. core_alua_do_transition_tg_pt would then only set
tg_pt_gp_alua_pending_state and the tg_pt_gp_alua_access_state would
not get updated with the second calls state.
2. core_alua_do_transition_tg_pt could be setting
tg_pt_gp_transition_complete while the tg_pt_gp_transition_work
is already completing. core_alua_do_transition_tg_pt then waits on the
completion that will never be called.
To handle these issues, we just call flush_work which will return when
core_alua_do_transition_tg_pt_work has completed so there is no need
to do the complete/wait. And, if core_alua_do_transition_tg_pt_work
was running, instead of trying to sneak in the state change, we just
schedule up another core_alua_do_transition_tg_pt_work call.
Note that this does not handle a possible race where there are multiple
threads call core_alua_do_transition_tg_pt at the same time. I think
we need a mutex in target_tg_pt_gp_alua_access_state_store.
Signed-off-by: Mike Christie <mchristi(a)redhat.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/target_core_alua.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
--- a/drivers/target/target_core_alua.c
+++ b/drivers/target/target_core_alua.c
@@ -1073,16 +1073,8 @@ static int core_alua_do_transition_tg_pt
/*
* Flush any pending transitions
*/
- if (!explicit && atomic_read(&tg_pt_gp->tg_pt_gp_alua_access_state) ==
- ALUA_ACCESS_STATE_TRANSITION) {
- /* Just in case */
- tg_pt_gp->tg_pt_gp_alua_pending_state = new_state;
- tg_pt_gp->tg_pt_gp_transition_complete = &wait;
+ if (!explicit)
flush_work(&tg_pt_gp->tg_pt_gp_transition_work);
- wait_for_completion(&wait);
- tg_pt_gp->tg_pt_gp_transition_complete = NULL;
- return 0;
- }
/*
* Save the old primary ALUA access state, and set the current state
Patches currently in stable-queue which might be from mchristi(a)redhat.com are
queue-4.9/target-use-system-workqueue-for-alua-transitions.patch
queue-4.9/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch
queue-4.9/target-fix-alua-transition-timeout-handling.patch
queue-4.9/target-fix-race-during-implicit-transition-work-flushes.patch
This is a note to let you know that I've just added the patch titled
target:fix condition return in core_pr_dump_initiator_port()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
target-fix-condition-return-in-core_pr_dump_initiator_port.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:12:35 CET 2017
From: tangwenji <tang.wenji(a)zte.com.cn>
Date: Thu, 24 Aug 2017 19:59:37 +0800
Subject: target:fix condition return in core_pr_dump_initiator_port()
From: tangwenji <tang.wenji(a)zte.com.cn>
[ Upstream commit 24528f089d0a444070aa4f715ace537e8d6bf168 ]
When is pr_reg->isid_present_at_reg is false,this function should return.
This fixes a regression originally introduced by:
commit d2843c173ee53cf4c12e7dfedc069a5bc76f0ac5
Author: Andy Grover <agrover(a)redhat.com>
Date: Thu May 16 10:40:55 2013 -0700
target: Alter core_pr_dump_initiator_port for ease of use
Signed-off-by: tangwenji <tang.wenji(a)zte.com.cn>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/target_core_pr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/target/target_core_pr.c
+++ b/drivers/target/target_core_pr.c
@@ -56,8 +56,10 @@ void core_pr_dump_initiator_port(
char *buf,
u32 size)
{
- if (!pr_reg->isid_present_at_reg)
+ if (!pr_reg->isid_present_at_reg) {
buf[0] = '\0';
+ return;
+ }
snprintf(buf, size, ",i,0x%s", pr_reg->pr_reg_isid);
}
Patches currently in stable-queue which might be from tang.wenji(a)zte.com.cn are
queue-4.9/target-fix-condition-return-in-core_pr_dump_initiator_port.patch
queue-4.9/iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch
This is a note to let you know that I've just added the patch titled
target: fix ALUA transition timeout handling
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
target-fix-alua-transition-timeout-handling.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:12:34 CET 2017
From: Mike Christie <mchristi(a)redhat.com>
Date: Thu, 2 Mar 2017 04:59:48 -0600
Subject: target: fix ALUA transition timeout handling
From: Mike Christie <mchristi(a)redhat.com>
[ Upstream commit d7175373f2745ed4abe5b388d5aabd06304f801e ]
The implicit transition time tells initiators the min time
to wait before timing out a transition. We currently schedule
the transition to occur in tg_pt_gp_implicit_trans_secs
seconds so there is no room for delays. If
core_alua_do_transition_tg_pt_work->core_alua_update_tpg_primary_metadata
needs to write out info to a remote file, then the initiator can
easily time out the operation.
Signed-off-by: Mike Christie <mchristi(a)redhat.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/target_core_alua.c | 23 ++++++++---------------
include/target/target_core_base.h | 2 +-
2 files changed, 9 insertions(+), 16 deletions(-)
--- a/drivers/target/target_core_alua.c
+++ b/drivers/target/target_core_alua.c
@@ -1010,7 +1010,7 @@ static void core_alua_queue_state_change
static void core_alua_do_transition_tg_pt_work(struct work_struct *work)
{
struct t10_alua_tg_pt_gp *tg_pt_gp = container_of(work,
- struct t10_alua_tg_pt_gp, tg_pt_gp_transition_work.work);
+ struct t10_alua_tg_pt_gp, tg_pt_gp_transition_work);
struct se_device *dev = tg_pt_gp->tg_pt_gp_dev;
bool explicit = (tg_pt_gp->tg_pt_gp_alua_access_status ==
ALUA_STATUS_ALTERED_BY_EXPLICIT_STPG);
@@ -1073,13 +1073,12 @@ static int core_alua_do_transition_tg_pt
/*
* Flush any pending transitions
*/
- if (!explicit && tg_pt_gp->tg_pt_gp_implicit_trans_secs &&
- atomic_read(&tg_pt_gp->tg_pt_gp_alua_access_state) ==
+ if (!explicit && atomic_read(&tg_pt_gp->tg_pt_gp_alua_access_state) ==
ALUA_ACCESS_STATE_TRANSITION) {
/* Just in case */
tg_pt_gp->tg_pt_gp_alua_pending_state = new_state;
tg_pt_gp->tg_pt_gp_transition_complete = &wait;
- flush_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work);
+ flush_work(&tg_pt_gp->tg_pt_gp_transition_work);
wait_for_completion(&wait);
tg_pt_gp->tg_pt_gp_transition_complete = NULL;
return 0;
@@ -1114,15 +1113,9 @@ static int core_alua_do_transition_tg_pt
atomic_inc(&tg_pt_gp->tg_pt_gp_ref_cnt);
spin_unlock(&dev->t10_alua.tg_pt_gps_lock);
- if (!explicit && tg_pt_gp->tg_pt_gp_implicit_trans_secs) {
- unsigned long transition_tmo;
-
- transition_tmo = tg_pt_gp->tg_pt_gp_implicit_trans_secs * HZ;
- schedule_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work,
- transition_tmo);
- } else {
+ schedule_work(&tg_pt_gp->tg_pt_gp_transition_work);
+ if (explicit) {
tg_pt_gp->tg_pt_gp_transition_complete = &wait;
- schedule_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work, 0);
wait_for_completion(&wait);
tg_pt_gp->tg_pt_gp_transition_complete = NULL;
}
@@ -1690,8 +1683,8 @@ struct t10_alua_tg_pt_gp *core_alua_allo
mutex_init(&tg_pt_gp->tg_pt_gp_md_mutex);
spin_lock_init(&tg_pt_gp->tg_pt_gp_lock);
atomic_set(&tg_pt_gp->tg_pt_gp_ref_cnt, 0);
- INIT_DELAYED_WORK(&tg_pt_gp->tg_pt_gp_transition_work,
- core_alua_do_transition_tg_pt_work);
+ INIT_WORK(&tg_pt_gp->tg_pt_gp_transition_work,
+ core_alua_do_transition_tg_pt_work);
tg_pt_gp->tg_pt_gp_dev = dev;
atomic_set(&tg_pt_gp->tg_pt_gp_alua_access_state,
ALUA_ACCESS_STATE_ACTIVE_OPTIMIZED);
@@ -1799,7 +1792,7 @@ void core_alua_free_tg_pt_gp(
dev->t10_alua.alua_tg_pt_gps_counter--;
spin_unlock(&dev->t10_alua.tg_pt_gps_lock);
- flush_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work);
+ flush_work(&tg_pt_gp->tg_pt_gp_transition_work);
/*
* Allow a struct t10_alua_tg_pt_gp_member * referenced by
--- a/include/target/target_core_base.h
+++ b/include/target/target_core_base.h
@@ -297,7 +297,7 @@ struct t10_alua_tg_pt_gp {
struct list_head tg_pt_gp_lun_list;
struct se_lun *tg_pt_gp_alua_lun;
struct se_node_acl *tg_pt_gp_alua_nacl;
- struct delayed_work tg_pt_gp_transition_work;
+ struct work_struct tg_pt_gp_transition_work;
struct completion *tg_pt_gp_transition_complete;
};
Patches currently in stable-queue which might be from mchristi(a)redhat.com are
queue-4.9/target-use-system-workqueue-for-alua-transitions.patch
queue-4.9/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch
queue-4.9/target-fix-alua-transition-timeout-handling.patch
queue-4.9/target-fix-race-during-implicit-transition-work-flushes.patch
This is a note to let you know that I've just added the patch titled
target/file: Do not return error for UNMAP if length is zero
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
target-file-do-not-return-error-for-unmap-if-length-is-zero.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:12:35 CET 2017
From: Jiang Yi <jiangyilism(a)gmail.com>
Date: Fri, 11 Aug 2017 11:29:44 +0800
Subject: target/file: Do not return error for UNMAP if length is zero
From: Jiang Yi <jiangyilism(a)gmail.com>
[ Upstream commit 594e25e73440863981032d76c9b1e33409ceff6e ]
The function fd_execute_unmap() in target_core_file.c calles
ret = file->f_op->fallocate(file, mode, pos, len);
Some filesystems implement fallocate() to return error if
length is zero (e.g. btrfs) but according to SCSI Block
Commands spec UNMAP should return success for zero length.
Signed-off-by: Jiang Yi <jiangyilism(a)gmail.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/target_core_file.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -466,6 +466,10 @@ fd_execute_unmap(struct se_cmd *cmd, sec
struct inode *inode = file->f_mapping->host;
int ret;
+ if (!nolb) {
+ return 0;
+ }
+
if (cmd->se_dev->dev_attrib.pi_prot_type) {
ret = fd_do_prot_unmap(cmd, lba, nolb);
if (ret)
Patches currently in stable-queue which might be from jiangyilism(a)gmail.com are
queue-4.9/target-file-do-not-return-error-for-unmap-if-length-is-zero.patch
This is a note to let you know that I've just added the patch titled
soc: mediatek: pwrap: fix compiler errors
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
soc-mediatek-pwrap-fix-compiler-errors.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:12:35 CET 2017
From: Matthias Brugger <matthias.bgg(a)gmail.com>
Date: Sat, 21 Oct 2017 10:17:47 +0200
Subject: soc: mediatek: pwrap: fix compiler errors
From: Matthias Brugger <matthias.bgg(a)gmail.com>
[ Upstream commit fb2c1934f30577756e55e24e8870b45c78da3bc2 ]
When compiling using sparse, we got the following error:
drivers/soc/mediatek/mtk-pmic-wrap.c:686:25: error: dubious one-bit signed bitfield
Changing the data type to unsigned fixes this.
Signed-off-by: Matthias Brugger <matthias.bgg(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/soc/mediatek/mtk-pmic-wrap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -522,7 +522,7 @@ struct pmic_wrapper_type {
u32 int_en_all;
u32 spi_w;
u32 wdt_src;
- int has_bridge:1;
+ unsigned int has_bridge:1;
int (*init_reg_clock)(struct pmic_wrapper *wrp);
int (*init_soc_specific)(struct pmic_wrapper *wrp);
};
Patches currently in stable-queue which might be from matthias.bgg(a)gmail.com are
queue-4.9/soc-mediatek-pwrap-fix-compiler-errors.patch
queue-4.9/iommu-mediatek-fix-driver-name.patch
This is a note to let you know that I've just added the patch titled
sfc: don't warn on successful change of MAC
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sfc-don-t-warn-on-successful-change-of-mac.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:12:34 CET 2017
From: Robert Stonehouse <rstonehouse(a)solarflare.com>
Date: Tue, 7 Nov 2017 17:30:30 +0000
Subject: sfc: don't warn on successful change of MAC
From: Robert Stonehouse <rstonehouse(a)solarflare.com>
[ Upstream commit cbad52e92ad7f01f0be4ca58bde59462dc1afe3a ]
Fixes: 535a61777f44e ("sfc: suppress handled MCDI failures when changing the MAC address")
Signed-off-by: Bert Kenward <bkenward(a)solarflare.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/sfc/ef10.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -4967,7 +4967,7 @@ static int efx_ef10_set_mac_address(stru
* MCFW do not support VFs.
*/
rc = efx_ef10_vport_set_mac_address(efx);
- } else {
+ } else if (rc) {
efx_mcdi_display_error(efx, MC_CMD_VADAPTOR_SET_MAC,
sizeof(inbuf), NULL, 0, rc);
}
Patches currently in stable-queue which might be from rstonehouse(a)solarflare.com are
queue-4.9/sfc-don-t-warn-on-successful-change-of-mac.patch
This is a note to let you know that I've just added the patch titled
scsi: sd: change manage_start_stop to bool in sysfs interface
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-sd-change-manage_start_stop-to-bool-in-sysfs-interface.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:12:35 CET 2017
From: weiping zhang <zhangweiping(a)didichuxing.com>
Date: Thu, 12 Oct 2017 14:57:06 +0800
Subject: scsi: sd: change manage_start_stop to bool in sysfs interface
From: weiping zhang <zhangweiping(a)didichuxing.com>
[ Upstream commit 623401ee33e42cee64d333877892be8db02951eb ]
/sys/class/scsi_disk/0:2:0:0/manage_start_stop can be changed to 0
unexpectly by writing an invalid string.
Signed-off-by: weiping zhang <zhangweiping(a)didichuxing.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sd.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -234,11 +234,15 @@ manage_start_stop_store(struct device *d
{
struct scsi_disk *sdkp = to_scsi_disk(dev);
struct scsi_device *sdp = sdkp->device;
+ bool v;
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
- sdp->manage_start_stop = simple_strtoul(buf, NULL, 10);
+ if (kstrtobool(buf, &v))
+ return -EINVAL;
+
+ sdp->manage_start_stop = v;
return count;
}
Patches currently in stable-queue which might be from zhangweiping(a)didichuxing.com are
queue-4.9/scsi-sd-change-allow_restart-to-bool-in-sysfs-interface.patch
queue-4.9/scsi-sd-change-manage_start_stop-to-bool-in-sysfs-interface.patch
This is a note to let you know that I've just added the patch titled
scsi: sd: change allow_restart to bool in sysfs interface
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-sd-change-allow_restart-to-bool-in-sysfs-interface.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:12:35 CET 2017
From: weiping zhang <zhangweiping(a)didichuxing.com>
Date: Thu, 12 Oct 2017 14:56:44 +0800
Subject: scsi: sd: change allow_restart to bool in sysfs interface
From: weiping zhang <zhangweiping(a)didichuxing.com>
[ Upstream commit 658e9a6dc1126f21fa417cd213e1cdbff8be0ba2 ]
/sys/class/scsi_disk/0:2:0:0/allow_restart can be changed to 0
unexpectedly by writing an invalid string such as the following:
echo asdf > /sys/class/scsi_disk/0:2:0:0/allow_restart
Signed-off-by: weiping zhang <zhangweiping(a)didichuxing.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sd.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -260,6 +260,7 @@ static ssize_t
allow_restart_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
+ bool v;
struct scsi_disk *sdkp = to_scsi_disk(dev);
struct scsi_device *sdp = sdkp->device;
@@ -269,7 +270,10 @@ allow_restart_store(struct device *dev,
if (sdp->type != TYPE_DISK)
return -EINVAL;
- sdp->allow_restart = simple_strtoul(buf, NULL, 10);
+ if (kstrtobool(buf, &v))
+ return -EINVAL;
+
+ sdp->allow_restart = v;
return count;
}
Patches currently in stable-queue which might be from zhangweiping(a)didichuxing.com are
queue-4.9/scsi-sd-change-allow_restart-to-bool-in-sysfs-interface.patch
queue-4.9/scsi-sd-change-manage_start_stop-to-bool-in-sysfs-interface.patch
This is a note to let you know that I've just added the patch titled
scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-scsi_devinfo-add-reportlun2-to-emc-symmetrix-blacklist-entry.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:12:35 CET 2017
From: Kurt Garloff <garloff(a)suse.de>
Date: Tue, 17 Oct 2017 09:10:45 +0200
Subject: scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry
From: Kurt Garloff <garloff(a)suse.de>
[ Upstream commit 909cf3e16a5274fe2127cf3cea5c8dba77b2c412 ]
All EMC SYMMETRIX support REPORT_LUNS, even if configured to report
SCSI-2 for whatever reason.
Signed-off-by: Kurt Garloff <garloff(a)suse.de>
Signed-off-by: Hannes Reinecke <hare(a)suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/scsi_devinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -160,7 +160,7 @@ static struct {
{"DGC", "RAID", NULL, BLIST_SPARSELUN}, /* Dell PV 650F, storage on LUN 0 */
{"DGC", "DISK", NULL, BLIST_SPARSELUN}, /* Dell PV 650F, no storage on LUN 0 */
{"EMC", "Invista", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
- {"EMC", "SYMMETRIX", NULL, BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_FORCELUN},
+ {"EMC", "SYMMETRIX", NULL, BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_REPORTLUN2},
{"EMULEX", "MD21/S2 ESDI", NULL, BLIST_SINGLELUN},
{"easyRAID", "16P", NULL, BLIST_NOREPORTLUN},
{"easyRAID", "X6P", NULL, BLIST_NOREPORTLUN},
Patches currently in stable-queue which might be from garloff(a)suse.de are
queue-4.9/scsi-scsi_devinfo-add-reportlun2-to-emc-symmetrix-blacklist-entry.patch
This is a note to let you know that I've just added the patch titled
scsi: scsi_debug: write_same: fix error report
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-scsi_debug-write_same-fix-error-report.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:12:35 CET 2017
From: Douglas Gilbert <dgilbert(a)interlog.com>
Date: Sun, 29 Oct 2017 10:47:19 -0400
Subject: scsi: scsi_debug: write_same: fix error report
From: Douglas Gilbert <dgilbert(a)interlog.com>
[ Upstream commit e33d7c56450b0a5c7290cbf9e1581fab5174f552 ]
The scsi_debug driver incorrectly suggests there is an error with the
SCSI WRITE SAME command when the number_of_logical_blocks is greater
than 1. It will also suggest there is an error when NDOB
(no data-out buffer) is set and the number_of_logical_blocks is
greater than 0. Both are valid, fix.
Signed-off-by: Douglas Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/scsi_debug.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -2996,11 +2996,11 @@ static int resp_write_same(struct scsi_c
if (-1 == ret) {
write_unlock_irqrestore(&atomic_rw, iflags);
return DID_ERROR << 16;
- } else if (sdebug_verbose && (ret < (num * sdebug_sector_size)))
+ } else if (sdebug_verbose && !ndob && (ret < sdebug_sector_size))
sdev_printk(KERN_INFO, scp->device,
- "%s: %s: cdb indicated=%u, IO sent=%d bytes\n",
+ "%s: %s: lb size=%u, IO sent=%d bytes\n",
my_name, "write same",
- num * sdebug_sector_size, ret);
+ sdebug_sector_size, ret);
/* Copy first sector to remaining blocks */
for (i = 1 ; i < num ; i++)
Patches currently in stable-queue which might be from dgilbert(a)interlog.com are
queue-4.9/scsi-scsi_debug-write_same-fix-error-report.patch