Re: [PATCH v2 2/7] drivers/base: Verify struct device locking requirements at runtime

[Greg Kroah-Hartman]

On Wed, Oct 17, 2018 at 04:40:01PM -0700, Bart Van Assche wrote:
> Make sure that a complaint appears in the kernel log if the driver core
> locking assumptions are violated.
> 
> Cc: Lee Duncan 
> Cc: Hannes Reinecke 
> Cc: Luis Chamberlain 
> Cc: Johannes Thumshirn 
> Cc: Christoph Hellwig 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Bart Van Assche 
> ---
>  drivers/base/dd.c | 16 
>  drivers/base/memory.c |  4 
>  2 files changed, 20 insertions(+)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index b4212154a94b..033382421351 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -315,11 +315,15 @@ __exitcall(deferred_probe_exit);
>   */
>  bool device_is_bound(struct device *dev)
>  {
> + lockdep_assert_held(>mutex);

With this patch applied, are you seeing lockdep messages anywhere?

thanks,

greg k-h

Re: [PATCH v2 1/7] drivers/base: Fix a race condition in the device probing code

[Greg Kroah-Hartman]

On Wed, Oct 17, 2018 at 04:40:00PM -0700, Bart Van Assche wrote:
> This patch avoids that complaints similar to the following appear in the
> system log:
> 
> sysfs: cannot create duplicate filename 
> '/devices/pseudo_0/adapter0/host3/target3:0:0/3:0:0:133/driver'
> 
> Cc: Lee Duncan 
> Cc: Hannes Reinecke 
> Cc: Luis Chamberlain 
> Cc: Johannes Thumshirn 
> Cc: Christoph Hellwig 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Bart Van Assche 
> ---
>  drivers/base/dd.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index edfc9f0b1180..b4212154a94b 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -645,6 +645,14 @@ int driver_probe_device(struct device_driver *drv, 
> struct device *dev)
>  {
>   int ret = 0;
>  
> + /*
> +  * Several callers check the driver pointer without holding the
> +  * device mutex. Hence check the driver pointer again while holding
> +  * the device mutex.
> +  */
> + if (dev->driver)
> + return dev->driver == drv;

I do not understand, who is calling probe twice?  What is the sequence
of events that is causing that error message being printed out?  Wh is
not grabbing the mutex properly?

thanks,

greg k-h

Re: [PATCH 1/2] sysfs: Introduce sysfs_{un,}break_active_protection()

[Greg Kroah-Hartman]

On Mon, Jul 30, 2018 at 11:40:51AM -0700, Bart Van Assche wrote:
> Introduce these two functions and export them such that the next patch
> can add calls to these functions from the SCSI core.
> 
> Signed-off-by: Bart Van Assche 
> Cc: Greg Kroah-Hartman 
> Cc: Tejun Heo 
> Cc: 
> ---
>  fs/sysfs/file.c   | 44 +++
>  include/linux/sysfs.h | 14 ++
>  2 files changed, 58 insertions(+)

Acked-by: Greg Kroah-Hartman 

Re: [PATCH] klist: Make it safe to use klists in atomic context

[Greg Kroah-Hartman]

On Fri, Jun 22, 2018 at 02:54:49PM -0700, Bart Van Assche wrote:
> In the scsi_transport_srp implementation it cannot be avoided to
> iterate over a klist from atomic context when using the legacy
> block layer instead of blk-mq. Hence this patch that makes it safe
> to use klists in atomic context. This patch avoids that lockdep
> reports the following:
> 
> WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
>  Possible interrupt unsafe locking scenario:
> 
>CPU0CPU1
>
>   lock(&(>k_lock)->rlock);
>local_irq_disable();
>lock(&(>__queue_lock)->rlock);
>lock(&(>k_lock)->rlock);
>   
> lock(&(>__queue_lock)->rlock);
> 
> stack backtrace:
> Workqueue: kblockd blk_timeout_work
> Call Trace:
>  dump_stack+0xa4/0xf5
>  check_usage+0x6e6/0x700
>  __lock_acquire+0x185d/0x1b50
>  lock_acquire+0xd2/0x260
>  _raw_spin_lock+0x32/0x50
>  klist_next+0x47/0x190
>  device_for_each_child+0x8e/0x100
>  srp_timed_out+0xaf/0x1d0 [scsi_transport_srp]
>  scsi_times_out+0xd4/0x410 [scsi_mod]
>  blk_rq_timed_out+0x36/0x70
>  blk_timeout_work+0x1b5/0x220
>  process_one_work+0x4fe/0xad0
>  worker_thread+0x63/0x5a0
>  kthread+0x1c1/0x1e0
>  ret_from_fork+0x24/0x30
> 
> See also commit c9ddf73476ff ("scsi: scsi_transport_srp: Fix shost
> to rport translation").
> 
> Signed-off-by: Bart Van Assche 
> Cc: Martin K. Petersen 
> Cc: James Bottomley 
> ---
>  lib/klist.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)

No objection from me:
Acked-by: Greg Kroah-Hartman 

This should probably go through the scsi tree, right?

thanks,

greg k-h

Re: [PATCH v2 0/2] 4.14 long term stable ZBC fixes

[Greg Kroah-Hartman]

On Mon, Jun 04, 2018 at 05:04:11PM +0900, Damien Le Moal wrote:
> Patch 4b433924b275 ("scsi: sd_zbc: Fix potential memory leak") was added in
> 4.16 and 4.15 stable but did not make it to long term stable 4.14 (as far as I
> can tell).
> 
> Patch ccce20fc7968 ("scsi: sd_zbc: Avoid that resetting a zone fails
> sporadically") is included in 4.16 but does not apply to 4.15 stable nor to
> 4.14 long term stable and requires extensive modifications.
> 
> This small series provides a backport of both patches against 4.14. Please
> consider these patches for inclusion in this long term stable kernel.

Both now queued up, thanks.

greg k-h

Re: [PATCH 1/2] scsi: sd_zbc: Fix potential memory leak

[Greg Kroah-Hartman]

On Thu, May 31, 2018 at 07:31:23PM +0900, Damien Le Moal wrote:
> [Backport of upstream commit 0aa3fdb8b3a6df3c2e3b61dbfe079db9d30e03cd]

That is not what this commit id is :(

Please fix up and resend the series.

thanks,

greg k-h

[PATCH 4.16 108/161] scsi: devinfo: add HP DISK-SUBSYSTEM device, for HP XP arrays

[Greg Kroah-Hartman]

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Xose Vazquez Perez <xose.vazq...@gmail.com>

[ Upstream commit 5f96f42b76e00e2871033745ff029056cc725c76 ]

"The DISK-SUBSYSTEM is a special model name returned when LUs
are not installed. For example, when LU#0 is not installed in "OPEN-"
models, LU#0 is detected as the DISK-SUBSYSTEM model":
https://marc.info/?l=linux-scsi=125424006417825

It's missing for HP XP rebranded arrays, "HP"/"OPEN-".
Only the HITACHI one is present:
13f7e5acc8b329080672c13f05f252ace5b79825
627511e3e67553b04f6917c03e39b797df210e04

Cc: Anthony Cheung <anthony.che...@hpe.com>
Cc: Takahiro Yasui <takahiro.ya...@hitachivantara.com>
Cc: Matthias Rudolph <matthias.rudo...@hitachivantara.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: James E.J. Bottomley <j...@linux.vnet.ibm.com>
Cc: SCSI ML <linux-scsi@vger.kernel.org>
Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com>
Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/scsi/scsi_devinfo.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -189,6 +189,7 @@ static struct {
{"HP", "C5713A", NULL, BLIST_NOREPORTLUN},
{"HP", "DF400", "*", BLIST_REPORTLUN2},
{"HP", "DF500", "*", BLIST_REPORTLUN2},
+   {"HP", "DISK-SUBSYSTEM", "*", BLIST_REPORTLUN2},
{"HP", "OP-C-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HP", "3380-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HP", "3390-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},

Re: [PATCH 41/42] tty: replace ->proc_fops with ->proc_show

[Greg Kroah-Hartman]

On Wed, May 16, 2018 at 11:43:45AM +0200, Christoph Hellwig wrote:
> Just set up the show callback in the tty_operations, and use
> proc_create_single_data to create the file without additional
> boilerplace code.
> 
> Signed-off-by: Christoph Hellwig <h...@lst.de>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

[PATCH 4.14 071/183] scsi: devinfo: fix format of the device list

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Xose Vazquez Perez <xose.vazq...@gmail.com>


[ Upstream commit 3f884a0a8bdf28cfd1e9987d54d83350096cdd46 ]

Replace "" with NULL for product revision level, and merge TEXEL
duplicate entries.

Cc: Hannes Reinecke <h...@suse.de>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: James E.J. Bottomley <j...@linux.vnet.ibm.com>
Cc: SCSI ML <linux-scsi@vger.kernel.org>
Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com>
Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/scsi/scsi_devinfo.c |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -109,8 +109,8 @@ static struct {
 * seagate controller, which causes SCSI code to reset bus.
 */
{"HP", "C1750A", "3226", BLIST_NOLUN},  /* scanjet iic */
-   {"HP", "C1790A", "", BLIST_NOLUN},  /* scanjet iip */
-   {"HP", "C2500A", "", BLIST_NOLUN},  /* scanjet iicx */
+   {"HP", "C1790A", NULL, BLIST_NOLUN},/* scanjet iip */
+   {"HP", "C2500A", NULL, BLIST_NOLUN},/* scanjet iicx */
{"MEDIAVIS", "CDR-H93MV", "1.31", BLIST_NOLUN}, /* locks up */
{"MICROTEK", "ScanMaker II", "5.61", BLIST_NOLUN},  /* responds to 
all lun */
{"MITSUMI", "CD-R CR-2201CS", "6119", BLIST_NOLUN}, /* locks up */
@@ -120,7 +120,7 @@ static struct {
{"QUANTUM", "FIREBALL ST4.3S", "0F0C", BLIST_NOLUN},/* locks up */
{"RELISYS", "Scorpio", NULL, BLIST_NOLUN},  /* responds to all lun 
*/
{"SANKYO", "CP525", "6.64", BLIST_NOLUN},   /* causes failed REQ 
SENSE, extra reset */
-   {"TEXEL", "CD-ROM", "1.06", BLIST_NOLUN},
+   {"TEXEL", "CD-ROM", "1.06", BLIST_NOLUN | BLIST_BORKEN},
{"transtec", "T5008", "0001", BLIST_NOREPORTLUN },
{"YAMAHA", "CDR100", "1.00", BLIST_NOLUN},  /* locks up */
{"YAMAHA", "CDR102", "1.00", BLIST_NOLUN},  /* locks up */
@@ -255,7 +255,6 @@ static struct {
{"ST650211", "CF", NULL, BLIST_RETRY_HWERROR},
{"SUN", "T300", "*", BLIST_SPARSELUN},
{"SUN", "T4", "*", BLIST_SPARSELUN},
-   {"TEXEL", "CD-ROM", "1.06", BLIST_BORKEN},
{"Tornado-", "F4", "*", BLIST_NOREPORTLUN},
{"TOSHIBA", "CDROM", NULL, BLIST_ISROM},
{"TOSHIBA", "CD-ROM", NULL, BLIST_ISROM},

Re: [PATCH 01/10] staging: fnic2 add initialization

[Greg Kroah-Hartman]

On Fri, Apr 06, 2018 at 03:00:11PM -0700, Oliver Smith-Denny wrote:
> On Fri, Apr 06, 2018 at 07:07:52AM +0200, Greg Kroah-Hartman wrote:
> > Why is this a drivers/staging/ driver at all?  What is keeping you from
> > getting this merged into the "proper" place in the kernel?
> > 
> > If you have a staging driver, you have to have a TODO file in the
> > directory listing what is keeping this in the staging section.
> 
> Sorry Greg, we do have a TODO file in the directory, but it was
> part of patch 10/10. I can move that to be part of patch 01/10.

Ah, I missed that, sorry.

> We think that this driver is a drivers/staging driver because
> there are some changes we want to make before submitting
> the driver to the "proper" place. Specifically, we want to
> change how we allocate memory (move from a static allocation
> to a mempool scenario), which will require some other code
> changes.

Why not just take a week and do that?  I can't take any new patches
until 4.17-rc1 is out anyway.

> Also, we want to investigate if we need to change our locking schema.

Again, why not just take the time to do that?

> We think that making this driver part of the drivers/staging community
> will allow interested people to try the driver in its current state
> and offer up ideas as to its continued development.

Have you asked the scsi developers what they think about this?

And why not copy the staging developer mailing list on this patch
series?

> If you think that this driver doesn't belong in the
> drivers/staging community, we are happy to explore getting
> the driver fully ready on our side and getting it into the
> "proper" place.

I'll take anything in staging as long as it has the correct license and
builds, that's not an issue :)  But I do want to get agreement from the
SCSI maintainers that this is ok to have in this part of the kernel as
sometimes it can cause merge issues if there are core api changes.

> > Please read the documentation on how to properly use SPDX tags on kernel
> > files.  This needs to be the first line of the file.
> 
> Thanks Greg, I fixed the SPDX tags and removed all the boilerplate,
> including the LICENSE file. Also, I have updated the MAINTAINERS
> file, which accidentally slipped by my first patch set. If you
> think that drivers/staging is a good temporary home for this
> driver, then I will send another patchset with the changes,
> as well as the changes from your other replies to patch 02/10
> and patch 03/10.

A respin of this would be nice, and again, I can't do anything with it
until 4.17-rc1 is out.

thanks,

greg k-h

Re: [PATCH 02/10] staging: fnic2 add resource allocation

[Greg Kroah-Hartman]

On Thu, Apr 05, 2018 at 02:17:52PM -0700, Oliver Smith-Denny wrote:
> --- /dev/null
> +++ b/drivers/staging/fnic2/src/fnic2_isr.c
> @@ -0,0 +1,324 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0
> + * Copyright 2018 Cisco Systems, Inc.  All rights reserved.
> + *
> + * This program is free software; you may redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + */

No need for the messy boilerplate text if you have a SPDX line, please
remove both of those paragraphs.

thanks,

greg k-h

Re: [PATCH 03/10] staging: fnic2 add fip handling

[Greg Kroah-Hartman]

On Thu, Apr 05, 2018 at 02:18:37PM -0700, Oliver Smith-Denny wrote:
> --- /dev/null
> +++ b/drivers/staging/fnic2/src/fip.c
> @@ -0,0 +1,804 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0
> + * Copyright 2018 Cisco Systems, Inc.  All rights reserved.
> + *
> + * This program is free software; you may redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + */
> +
> +/*! \file */

What is that line for?

Re: [PATCH 01/10] staging: fnic2 add initialization

[Greg Kroah-Hartman]

On Thu, Apr 05, 2018 at 02:16:45PM -0700, Oliver Smith-Denny wrote:
> These files contain module load and unload, global driver context,
> PCI registration, PCI probe and remove, and definitions of
> the fnic2 global context.
> 
> Signed-off-by: Oliver Smith-Denny 
> Signed-off-by: Sesidhar Baddela 
> Signed-off-by: Anil Chintalapati 
> Signed-off-by: Arulprabhu Ponnusamy 
> Signed-off-by: Gian Carlo Boffa 
> Co-Developed-by: Arulprabhu Ponnusamy 
> Co-Developed-by: Gian Carlo Boffa 
> Co-Developed-by: Oliver Smith-Denny 
> ---
>  drivers/staging/fnic2/src/fnic2.h  | 256 
>  drivers/staging/fnic2/src/fnic2_main.c | 711 
> +
>  2 files changed, 967 insertions(+)
>  create mode 100644 drivers/staging/fnic2/src/fnic2.h
>  create mode 100644 drivers/staging/fnic2/src/fnic2_main.c

Why is this a drivers/staging/ driver at all?  What is keeping you from
getting this merged into the "proper" place in the kernel?

If you have a staging driver, you have to have a TODO file in the
directory listing what is keeping this in the staging section.

Also, one tiny thing to fix up:

> --- /dev/null
> +++ b/drivers/staging/fnic2/src/fnic2.h
> @@ -0,0 +1,256 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0

Please read the documentation on how to properly use SPDX tags on kernel
files.  This needs to be the first line of the file.

thanks,

greg k-h

Re: [PATCH] Patch to replace DEFINE_SEMAPHORE with DEFINE_BINARY_SEMAPHORE

[Greg Kroah-Hartman]

On Sat, Mar 31, 2018 at 07:16:21PM +0530, Wasim Nazir wrote:
> This message contains confidential information and is intended only for the 
> individual(s) named. If you are not the intended recipient, you are 
> notified that disclosing, copying, distributing or taking any action in 
> reliance on the contents of this mail and attached file/s is strictly 
> prohibited. Please notify the sender immediately and delete this e-mail 
> from your system. E-mail transmission cannot be guaranteed to be secured or 
> error-free as information could be intercepted, corrupted, lost, destroyed, 
> arrive late or incomplete, or contain viruses. The sender therefore does 
> not accept liability for any errors or omissions in the contents of this 
> message, which arise as a result of e-mail transmission.


This footer is not compatible with patches submitted to the kernel,
sorry.  email is now deleted.

greg k-h

Re: SCSI generic (sg) regression in stable kernels

[Greg Kroah-Hartman]

On Wed, Mar 28, 2018 at 05:37:24PM -0400, Tony Battersby wrote:
> The SCSI generic driver is currently broken in the 3.18, 4.1, 4.4, and
> 4.9 stable kernels.  This is the problematic commit:
> 
> 109bade9c625 ("scsi: sg: use standard lists for sg_requests")
> 
> (all commit ids are from upstream git, not stable.git)
> 
> There have already been a number of fixes backported to -stable to fix
> problems introduced by that commit:
> 
> bd46fc406b30 ("scsi: sg: off by one in sg_ioctl()")
> 4759df905a47 ("scsi: sg: factor out sg_fill_request_table()")
> 3e0097499839 ("scsi: sg: fixup infoleak when using SG_GET_REQUEST_TABLE")
> 587c3c9f286c ("scsi: sg: Re-fix off by one in sg_fill_request_table()")
> 
> I am not sure why 109bade9c625 was added to -stable to begin with.  My
> guess is that the "infoleak" fix was flagged as being appropriate for
> -stable, and it depended on the original commit 109bade9c625.  But if
> you take a close look, the original commit 109bade9c625 is what
> introduced the infoleak in the first place.  Or maybe there was some
> other reason.  But I digress.
> 
> There is one more fix for 109bade9c625 that has not yet been backported:
> 
> 48ae8484e9fc ("scsi: sg: don't return bogus Sg_requests")
> 
> Without the fix above, sg oopses as soon as I try to use it.  So please
> add 48ae8484e9fc to -stable.
> 
> The following -stable kernels already have 48ae8484e9fc:
> 4.14.31
> 4.15.14
> 
> The following -stable kernels need 48ae8484e9fc:
> 3.18.102
> 4.1.51
> 4.4.125
> 4.9.91

Now queued up for 4.9.y, 4.4.y, and 3.18.y, thanks!

greg k-h

[PATCH 3.18 53/68] scsi: devinfo: apply to HP XP the same flags as Hitachi VSP

[Greg Kroah-Hartman]

3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Xose Vazquez Perez <xose.vazq...@gmail.com>


[ Upstream commit b369a0471503130cfc74f9f62071db97f48948c3 ]

Commit 56f3d383f37b ("scsi: scsi_devinfo: Add TRY_VPD_PAGES to HITACHI
OPEN-V blacklist entry") modified some Hitachi entries:

HITACHI is always supporting VPD pages, even though it's claiming to
support SCSI Revision 3 only.

The same should have been done also for HP-rebranded.

[mkp: checkpatch and tweaked commit message]

Cc: Hannes Reinecke <h...@suse.de>
Cc: Takahiro Yasui <takahiro.ya...@hds.com>
Cc: Matthias Rudolph <matthias.rudo...@hitachivantara.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: James E.J. Bottomley <j...@linux.vnet.ibm.com>
Cc: SCSI ML <linux-scsi@vger.kernel.org>
Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com>
Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@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
@@ -180,7 +180,7 @@ static struct {
{"HITACHI", "6586-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HITACHI", "6588-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HP", "A6189A", NULL, BLIST_SPARSELUN | BLIST_LARGELUN},   /* HP 
VA7400 */
-   {"HP", "OPEN-", "*", BLIST_REPORTLUN2}, /* HP XP Arrays */
+   {"HP", "OPEN-", "*", BLIST_REPORTLUN2 | BLIST_TRY_VPD_PAGES}, /* HP XP 
Arrays */
{"HP", "NetRAID-4M", NULL, BLIST_FORCELUN},
{"HP", "HSV100", NULL, BLIST_REPORTLUN2 | BLIST_NOSTARTONADD},
{"HP", "C1557A", NULL, BLIST_FORCELUN},

[PATCH 4.4 098/134] scsi: devinfo: apply to HP XP the same flags as Hitachi VSP

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Xose Vazquez Perez <xose.vazq...@gmail.com>


[ Upstream commit b369a0471503130cfc74f9f62071db97f48948c3 ]

Commit 56f3d383f37b ("scsi: scsi_devinfo: Add TRY_VPD_PAGES to HITACHI
OPEN-V blacklist entry") modified some Hitachi entries:

HITACHI is always supporting VPD pages, even though it's claiming to
support SCSI Revision 3 only.

The same should have been done also for HP-rebranded.

[mkp: checkpatch and tweaked commit message]

Cc: Hannes Reinecke <h...@suse.de>
Cc: Takahiro Yasui <takahiro.ya...@hds.com>
Cc: Matthias Rudolph <matthias.rudo...@hitachivantara.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: James E.J. Bottomley <j...@linux.vnet.ibm.com>
Cc: SCSI ML <linux-scsi@vger.kernel.org>
Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com>
Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@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
@@ -180,7 +180,7 @@ static struct {
{"HITACHI", "6586-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HITACHI", "6588-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HP", "A6189A", NULL, BLIST_SPARSELUN | BLIST_LARGELUN},   /* HP 
VA7400 */
-   {"HP", "OPEN-", "*", BLIST_REPORTLUN2}, /* HP XP Arrays */
+   {"HP", "OPEN-", "*", BLIST_REPORTLUN2 | BLIST_TRY_VPD_PAGES}, /* HP XP 
Arrays */
{"HP", "NetRAID-4M", NULL, BLIST_FORCELUN},
{"HP", "HSV100", NULL, BLIST_REPORTLUN2 | BLIST_NOSTARTONADD},
{"HP", "C1557A", NULL, BLIST_FORCELUN},

[PATCH 4.4 099/134] scsi: dh: add new rdac devices

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Xose Vazquez Perez <xose.vazq...@gmail.com>


[ Upstream commit 4b3aec2bbbce1c35f50e7475a9fd78d24b9ea4ea ]

Add IBM 3542 and 3552, arrays: FAStT200 and FAStT500.

Add full STK OPENstorage family, arrays: 9176, D173, D178, D210, D220,
D240 and D280.

Add STK BladeCtlr family, arrays: B210, B220, B240 and B280.

These changes were done in multipath-tools time ago.

Cc: NetApp RDAC team <ng-eseries-upstream-maintain...@netapp.com>
Cc: Hannes Reinecke <h...@suse.de>
Cc: Christophe Varoqui <christophe.varo...@opensvc.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: James E.J. Bottomley <j...@linux.vnet.ibm.com>
Cc: SCSI ML <linux-scsi@vger.kernel.org>
Cc: device-mapper development <dm-de...@redhat.com>
Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com>
Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/scsi/scsi_dh.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/scsi/scsi_dh.c
+++ b/drivers/scsi/scsi_dh.c
@@ -56,10 +56,13 @@ static const struct scsi_dh_blist scsi_d
{"IBM", "1815", "rdac", },
{"IBM", "1818", "rdac", },
{"IBM", "3526", "rdac", },
+   {"IBM", "3542", "rdac", },
+   {"IBM", "3552", "rdac", },
{"SGI", "TP9",  "rdac", },
{"SGI", "IS",   "rdac", },
-   {"STK", "OPENstorage D280", "rdac", },
+   {"STK", "OPENstorage",  "rdac", },
{"STK", "FLEXLINE 380", "rdac", },
+   {"STK", "BladeCtlr","rdac", },
{"SUN", "CSM",  "rdac", },
{"SUN", "LCSM100",  "rdac", },
{"SUN", "STK6580_6780", "rdac", },

[PATCH 4.9 195/241] scsi: devinfo: apply to HP XP the same flags as Hitachi VSP

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Xose Vazquez Perez <xose.vazq...@gmail.com>


[ Upstream commit b369a0471503130cfc74f9f62071db97f48948c3 ]

Commit 56f3d383f37b ("scsi: scsi_devinfo: Add TRY_VPD_PAGES to HITACHI
OPEN-V blacklist entry") modified some Hitachi entries:

HITACHI is always supporting VPD pages, even though it's claiming to
support SCSI Revision 3 only.

The same should have been done also for HP-rebranded.

[mkp: checkpatch and tweaked commit message]

Cc: Hannes Reinecke <h...@suse.de>
Cc: Takahiro Yasui <takahiro.ya...@hds.com>
Cc: Matthias Rudolph <matthias.rudo...@hitachivantara.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: James E.J. Bottomley <j...@linux.vnet.ibm.com>
Cc: SCSI ML <linux-scsi@vger.kernel.org>
Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com>
Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@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
@@ -180,7 +180,7 @@ static struct {
{"HITACHI", "6586-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HITACHI", "6588-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HP", "A6189A", NULL, BLIST_SPARSELUN | BLIST_LARGELUN},   /* HP 
VA7400 */
-   {"HP", "OPEN-", "*", BLIST_REPORTLUN2}, /* HP XP Arrays */
+   {"HP", "OPEN-", "*", BLIST_REPORTLUN2 | BLIST_TRY_VPD_PAGES}, /* HP XP 
Arrays */
{"HP", "NetRAID-4M", NULL, BLIST_FORCELUN},
{"HP", "HSV100", NULL, BLIST_REPORTLUN2 | BLIST_NOSTARTONADD},
{"HP", "C1557A", NULL, BLIST_FORCELUN},

[PATCH 4.9 196/241] scsi: dh: add new rdac devices

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Xose Vazquez Perez <xose.vazq...@gmail.com>


[ Upstream commit 4b3aec2bbbce1c35f50e7475a9fd78d24b9ea4ea ]

Add IBM 3542 and 3552, arrays: FAStT200 and FAStT500.

Add full STK OPENstorage family, arrays: 9176, D173, D178, D210, D220,
D240 and D280.

Add STK BladeCtlr family, arrays: B210, B220, B240 and B280.

These changes were done in multipath-tools time ago.

Cc: NetApp RDAC team <ng-eseries-upstream-maintain...@netapp.com>
Cc: Hannes Reinecke <h...@suse.de>
Cc: Christophe Varoqui <christophe.varo...@opensvc.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: James E.J. Bottomley <j...@linux.vnet.ibm.com>
Cc: SCSI ML <linux-scsi@vger.kernel.org>
Cc: device-mapper development <dm-de...@redhat.com>
Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com>
Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/scsi/scsi_dh.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/scsi/scsi_dh.c
+++ b/drivers/scsi/scsi_dh.c
@@ -56,10 +56,13 @@ static const struct scsi_dh_blist scsi_d
{"IBM", "1815", "rdac", },
{"IBM", "1818", "rdac", },
{"IBM", "3526", "rdac", },
+   {"IBM", "3542", "rdac", },
+   {"IBM", "3552", "rdac", },
{"SGI", "TP9",  "rdac", },
{"SGI", "IS",   "rdac", },
-   {"STK", "OPENstorage D280", "rdac", },
+   {"STK", "OPENstorage",  "rdac", },
{"STK", "FLEXLINE 380", "rdac", },
+   {"STK", "BladeCtlr","rdac", },
{"SUN", "CSM",  "rdac", },
{"SUN", "LCSM100",  "rdac", },
{"SUN", "STK6580_6780", "rdac", },

[PATCH 4.14 084/109] scsi: dh: add new rdac devices

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Xose Vazquez Perez <xose.vazq...@gmail.com>


[ Upstream commit 4b3aec2bbbce1c35f50e7475a9fd78d24b9ea4ea ]

Add IBM 3542 and 3552, arrays: FAStT200 and FAStT500.

Add full STK OPENstorage family, arrays: 9176, D173, D178, D210, D220,
D240 and D280.

Add STK BladeCtlr family, arrays: B210, B220, B240 and B280.

These changes were done in multipath-tools time ago.

Cc: NetApp RDAC team <ng-eseries-upstream-maintain...@netapp.com>
Cc: Hannes Reinecke <h...@suse.de>
Cc: Christophe Varoqui <christophe.varo...@opensvc.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: James E.J. Bottomley <j...@linux.vnet.ibm.com>
Cc: SCSI ML <linux-scsi@vger.kernel.org>
Cc: device-mapper development <dm-de...@redhat.com>
Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com>
Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/scsi/scsi_dh.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/scsi/scsi_dh.c
+++ b/drivers/scsi/scsi_dh.c
@@ -56,10 +56,13 @@ static const struct scsi_dh_blist scsi_d
{"IBM", "1815", "rdac", },
{"IBM", "1818", "rdac", },
{"IBM", "3526", "rdac", },
+   {"IBM", "3542", "rdac", },
+   {"IBM", "3552", "rdac", },
{"SGI", "TP9",  "rdac", },
{"SGI", "IS",   "rdac", },
-   {"STK", "OPENstorage D280", "rdac", },
+   {"STK", "OPENstorage",  "rdac", },
{"STK", "FLEXLINE 380", "rdac", },
+   {"STK", "BladeCtlr","rdac", },
{"SUN", "CSM",  "rdac", },
{"SUN", "LCSM100",  "rdac", },
{"SUN", "STK6580_6780", "rdac", },

[PATCH 4.15 100/128] scsi: devinfo: apply to HP XP the same flags as Hitachi VSP

[Greg Kroah-Hartman]

4.15-stable review patch.  If anyone has any objections, please let me know.

--

From: Xose Vazquez Perez <xose.vazq...@gmail.com>


[ Upstream commit b369a0471503130cfc74f9f62071db97f48948c3 ]

Commit 56f3d383f37b ("scsi: scsi_devinfo: Add TRY_VPD_PAGES to HITACHI
OPEN-V blacklist entry") modified some Hitachi entries:

HITACHI is always supporting VPD pages, even though it's claiming to
support SCSI Revision 3 only.

The same should have been done also for HP-rebranded.

[mkp: checkpatch and tweaked commit message]

Cc: Hannes Reinecke <h...@suse.de>
Cc: Takahiro Yasui <takahiro.ya...@hds.com>
Cc: Matthias Rudolph <matthias.rudo...@hitachivantara.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: James E.J. Bottomley <j...@linux.vnet.ibm.com>
Cc: SCSI ML <linux-scsi@vger.kernel.org>
Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com>
Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@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
@@ -181,7 +181,7 @@ static struct {
{"HITACHI", "6586-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HITACHI", "6588-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HP", "A6189A", NULL, BLIST_SPARSELUN | BLIST_LARGELUN},   /* HP 
VA7400 */
-   {"HP", "OPEN-", "*", BLIST_REPORTLUN2}, /* HP XP Arrays */
+   {"HP", "OPEN-", "*", BLIST_REPORTLUN2 | BLIST_TRY_VPD_PAGES}, /* HP XP 
Arrays */
{"HP", "NetRAID-4M", NULL, BLIST_FORCELUN},
{"HP", "HSV100", NULL, BLIST_REPORTLUN2 | BLIST_NOSTARTONADD},
{"HP", "C1557A", NULL, BLIST_FORCELUN},

[PATCH 4.15 101/128] scsi: dh: add new rdac devices

[Greg Kroah-Hartman]

4.15-stable review patch.  If anyone has any objections, please let me know.

--

From: Xose Vazquez Perez <xose.vazq...@gmail.com>


[ Upstream commit 4b3aec2bbbce1c35f50e7475a9fd78d24b9ea4ea ]

Add IBM 3542 and 3552, arrays: FAStT200 and FAStT500.

Add full STK OPENstorage family, arrays: 9176, D173, D178, D210, D220,
D240 and D280.

Add STK BladeCtlr family, arrays: B210, B220, B240 and B280.

These changes were done in multipath-tools time ago.

Cc: NetApp RDAC team <ng-eseries-upstream-maintain...@netapp.com>
Cc: Hannes Reinecke <h...@suse.de>
Cc: Christophe Varoqui <christophe.varo...@opensvc.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: James E.J. Bottomley <j...@linux.vnet.ibm.com>
Cc: SCSI ML <linux-scsi@vger.kernel.org>
Cc: device-mapper development <dm-de...@redhat.com>
Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com>
Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/scsi/scsi_dh.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/scsi/scsi_dh.c
+++ b/drivers/scsi/scsi_dh.c
@@ -56,10 +56,13 @@ static const struct scsi_dh_blist scsi_d
{"IBM", "1815", "rdac", },
{"IBM", "1818", "rdac", },
{"IBM", "3526", "rdac", },
+   {"IBM", "3542", "rdac", },
+   {"IBM", "3552", "rdac", },
{"SGI", "TP9",  "rdac", },
{"SGI", "IS",   "rdac", },
-   {"STK", "OPENstorage D280", "rdac", },
+   {"STK", "OPENstorage",  "rdac", },
{"STK", "FLEXLINE 380", "rdac", },
+   {"STK", "BladeCtlr","rdac", },
{"SUN", "CSM",  "rdac", },
{"SUN", "LCSM100",  "rdac", },
{"SUN", "STK6580_6780", "rdac", },

[PATCH 4.14 083/109] scsi: devinfo: apply to HP XP the same flags as Hitachi VSP

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Xose Vazquez Perez <xose.vazq...@gmail.com>


[ Upstream commit b369a0471503130cfc74f9f62071db97f48948c3 ]

Commit 56f3d383f37b ("scsi: scsi_devinfo: Add TRY_VPD_PAGES to HITACHI
OPEN-V blacklist entry") modified some Hitachi entries:

HITACHI is always supporting VPD pages, even though it's claiming to
support SCSI Revision 3 only.

The same should have been done also for HP-rebranded.

[mkp: checkpatch and tweaked commit message]

Cc: Hannes Reinecke <h...@suse.de>
Cc: Takahiro Yasui <takahiro.ya...@hds.com>
Cc: Matthias Rudolph <matthias.rudo...@hitachivantara.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: James E.J. Bottomley <j...@linux.vnet.ibm.com>
Cc: SCSI ML <linux-scsi@vger.kernel.org>
Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com>
Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@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
@@ -181,7 +181,7 @@ static struct {
{"HITACHI", "6586-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HITACHI", "6588-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HP", "A6189A", NULL, BLIST_SPARSELUN | BLIST_LARGELUN},   /* HP 
VA7400 */
-   {"HP", "OPEN-", "*", BLIST_REPORTLUN2}, /* HP XP Arrays */
+   {"HP", "OPEN-", "*", BLIST_REPORTLUN2 | BLIST_TRY_VPD_PAGES}, /* HP XP 
Arrays */
{"HP", "NetRAID-4M", NULL, BLIST_FORCELUN},
{"HP", "HSV100", NULL, BLIST_REPORTLUN2 | BLIST_NOSTARTONADD},
{"HP", "C1557A", NULL, BLIST_FORCELUN},

Re: [PATCH v2 3/5] usb: gadget: Add NO_DMA dummies for DMA mapping API

[Greg Kroah-Hartman]

On Fri, Mar 16, 2018 at 02:25:42PM +0100, Geert Uytterhoeven wrote:
> Add dummies for usb_gadget_{,un}map_request{,_by_dev}(), to allow
> compile-testing if NO_DMA=y.
> 
> This prevents the following from showing up later:
> 
> ERROR: "usb_gadget_unmap_request_by_dev" 
> [drivers/usb/renesas_usbhs/renesas_usbhs.ko] undefined!
> ERROR: "usb_gadget_map_request_by_dev" 
> [drivers/usb/renesas_usbhs/renesas_usbhs.ko] undefined!
> ERROR: "usb_gadget_map_request" [drivers/usb/mtu3/mtu3.ko] undefined!
> ERROR: "usb_gadget_unmap_request" [drivers/usb/mtu3/mtu3.ko] undefined!
> ERROR: "usb_gadget_map_request" [drivers/usb/gadget/udc/renesas_usb3.ko] 
> undefined!
> ERROR: "usb_gadget_unmap_request" 
> [drivers/usb/gadget/udc/renesas_usb3.ko] undefined!
> 
> Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
> Reviewed-by: Mark Brown <broo...@kernel.org>
> Acked-by: Robin Murphy <robin.mur...@arm.com>
> Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com>

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Re: iSCSI session logout regression after fbce4d97fd ("scsi: fixup kernel warning during rmmod()")

[Greg Kroah-Hartman]

On Mon, Feb 19, 2018 at 11:27:07PM +, Max Ivanov wrote:
> > As already explained in the previous mail, there is a fixup for this in
> > commit 81b6c9998979 ('scsi: core: check for device state in
> > __scsi_remove_target()').
> > Please check if this is applied, too.
> 
> I tested commit 81b6c9998979 cherry-picked on top of 4.14.20 and it
> indeed solves the problem.
> 
> Can it be backported to 4.14 LTS, please?

Now queued up, thanks.

greg k-h

Re: [PATCH 2/2 v4] scsi: ufs: introduce sysfs entries exposing UFS health info

[Greg Kroah-Hartman]

On Wed, Dec 27, 2017 at 09:00:10AM +, Avri Altman wrote:
> 
> 
> > -Original Message-
> > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> > ow...@vger.kernel.org] On Behalf Of Greg Kroah-Hartman
> > Sent: Thursday, December 21, 2017 10:00 AM
> > To: Jaegeuk Kim <jaeg...@kernel.org>
> > Cc: linux-ker...@vger.kernel.org; linux-scsi@vger.kernel.org; Jaegeuk Kim
> > <jaeg...@google.com>
> > Subject: Re: [PATCH 2/2 v4] scsi: ufs: introduce sysfs entries exposing UFS
> > health info
> > 
> > On Wed, Dec 20, 2017 at 02:13:25PM -0800, Jaegeuk Kim wrote:
> > > This patch adds a new sysfs group, namely health, via:
> > >
> > >/sys/devices/soc/X.ufshc/health/
> As device health is just one piece of information out of the device 
> management,
> I think that you should address this in a more comprehensive way,
> And set hooks for much more device info:
> Allow access to device descriptors, attributes and flags.

Add on patches are easy to create for this if people really want and
need it :)

> The attributes and flags should be placed in separate subfolders

Why?  What is that going to help with?

> The LUN specific descriptors and attributes should be placed in a luns
> subfolder, and then per descriptor / attribute type

Again, why?

> You might also would like to consider differentiating read and write -
> to control those type of accesses as well.

What do you mean by this exactly?

As it is, this is a step forward in getting attributes that people are
asking for and already using, into the kernel tree.  Please don't object
because not all attributes that are possible are being added here, it
should be trivial to add more as needed, right?

I'm really tired of seeing all of the various out-of-tree forks of this
driver, it's about time that someone works to get those features merged,
right?

thanks,

greg k-h

Re: [PATCH 2/2 v4] scsi: ufs: introduce sysfs entries exposing UFS health info

[Greg Kroah-Hartman]

On Wed, Dec 20, 2017 at 02:13:25PM -0800, Jaegeuk Kim wrote:
> This patch adds a new sysfs group, namely health, via:
> 
>/sys/devices/soc/X.ufshc/health/
> 
> This directory contains the below entries, each of which shows an 8-bytes
> hex number representing different meanings defined by JEDEC specfication.
> 
> Users can simply read these entries to check how their underlying flash
> storage is getting reached out to its end of life. For example, if
> lifetimeA shows 0xb, it would be the right time to consider device swap.
> 
>  - length
>: must be 25h
> 
>  - type
>: must be 09h
> 
>  - eol
>00h: Not defined
>01h: Normal
>02h: Warning
>03h: Critical
> 
>  - lifetimeA/B
>00h: Not defined
>01h:  0% ~ 10% device life time used
>02h: 10% ~ 20% device life time used
>03h: 20% ~ 30% device life time used
>04h: 30% ~ 40% device life time used
>05h: 40% ~ 50% device life time used
>06h: 50% ~ 60% device life time used
>07h: 60% ~ 70% device life time used
>08h: 70% ~ 80% device life time used
>09h: 80% ~ 90% device life time used
>0Ah: 90% ~ 100% device life time used
>0Bh: Exceeded its maximum estimated device life time
> 
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Signed-off-by: Jaegeuk Kim <jaeg...@google.com>
> ---

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Re: [PATCH 1/2 v3] scsi: ufs: introduce static sysfs entries

[Greg Kroah-Hartman]

On Wed, Dec 20, 2017 at 11:16:30AM -0800, Jaegeuk Kim wrote:
> From: Jaegeuk Kim <jaeg...@google.com>
> 
> This patch introduces attribute group to show existing sysfs entries.
> 
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Signed-off-by: Jaegeuk Kim <jaeg...@google.com>
> ---
> 
> Change log from v1:
>  - use ATTRIBUTE_GROUPS and sysfs_create_groups()

Nice change, thanks.

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Re: [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW

[Greg Kroah-Hartman]

On Wed, Dec 20, 2017 at 01:54:41AM -0800, Joe Perches wrote:
> On Wed, 2017-12-20 at 10:32 +0100, Greg Kroah-Hartman wrote:
> > On Wed, Dec 20, 2017 at 01:24:44AM -0800, Joe Perches wrote:
> > > On Wed, 2017-12-20 at 10:34 +0200, Jarkko Nikula wrote:
> > > > On Tue, Dec 19, 2017 at 10:15:07AM -0800, Joe Perches wrote:
> > > > > Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.
> > > 
> > > [] 
> > > > > diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
> > > 
> > > []
> > > > > @@ -854,7 +854,7 @@ static ssize_t dma_op_mode_store(struct device 
> > > > > *dev,
> > > > >   return size;
> > > > >  }
> > > > >  
> > > > > -static DEVICE_ATTR(dma_op_mode, 0644, dma_op_mode_show, 
> > > > > dma_op_mode_store);
> > > > > +static DEVICE_ATTR_RW(dma_op_mode);
> > > > >  
> > > > 
> > > > While I can ack this part here if it helps generic cleanup effort I
> > > > don't understart would it improve code readability in general? Mode 644
> > > > is clear and don't need any grepping but for DEVICE_ATTR_RW() I had to 
> > > > go
> > > > through all of these files in order to see what does it mean:
> > 
> > Yeah, 644 is "clear", but _RW() is even more clear.  Ideally I want to
> > get rid of all of the "non-standard" users that set random modes of
> > sysfs files, as we get it wrong too many times.  Using the "defaults" is
> > much better.
> > 
> > > Are you suggesting that device.h (as that is where
> > > DEVICE_ATTR and the other DEVICE_ATTR_ variants
> > > are #defined) should have better comments for the
> > > _ variants?
> > > 
> > > > DEVICE_ATTR_RW: include/linux/device.h
> > > > __ATTR_RW: include/linux/sysfs.h
> > > > S_IWUSR: include/uapi/linux/stat.h
> > > > S_IRUGO: include/linux/stat.h
> > > 
> > > btw: patch 1/4 of the series does remove the uses of
> > > S_ from these macros in sysfs.h and converts
> > > them to simple octal instead.
> > 
> > Why you didn't send that patch to the sysfs maintainer is a bit odd...  :)
> 
> So here's an opportunity for you:
> 
> The sysfs maintainer hasn't added include/linux/sysfs.h to
> the list of maintained files...
> 
> DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS
> M:Greg Kroah-Hartman <gre...@linuxfoundation.org>
> T:git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> S:Supported
> F:Documentation/kobject.txt
> F:drivers/base/
> F:fs/debugfs/
> F:fs/sysfs/
> F:include/linux/debugfs.h
> F:include/linux/kobj*
> F:lib/kobj*

Heh, good point, but using get_maintainer.pl does put me at the top of
the list that you should be cc:ing:

$ ./scripts/get_maintainer.pl --file include/linux/sysfs.h
Greg Kroah-Hartman <gre...@linuxfoundation.org> 
(commit_signer:3/3=100%,authored:2/3=67%,added_lines:7/8=88%)
Kate Stewart <kstew...@linuxfoundation.org> (commit_signer:1/3=33%)
Thomas Gleixner <t...@linutronix.de> (commit_signer:1/3=33%)
Philippe Ombredanne <pombreda...@nexb.com> (commit_signer:1/3=33%)
Nick Desaulniers <nick.desaulni...@gmail.com> 
(commit_signer:1/3=33%,authored:1/3=33%,added_lines:1/8=12%,removed_lines:1/1=100%)
linux-ker...@vger.kernel.org (open list)

Anyway, I'll go add sysfs.h to the list, thanks for pointing it out.

> > I should be taking this whole series through my tree.  Joe, thanks for
> > doing this in an automated way, I've been wanting to see this done for a
> > long time.
> 
> btw: there are many uses of a reversed declaration style of DEVICE_ATTR
> 
> Here's another thing that could be done for more DEVICE_ATTR_ uses.
> 
> ===
> 
> Some DEVICE_ATTR definitions use a reversed static function form from
> the typical.  Convert them to use the more common macro form so it is
> easier to grep for the style.
> 
> i.e.:
> static ssize_t show_(...)
> and
> static ssize_t store_(...)
> 
> where the static function names in the DEVICE_ATTR_RW macro are reversed
> 
> static ssize_t _show(...)
> and
> static ssize_t _store(...)
> 
> Done with perl script
> 
> $ cat dev_attr_rw_backwards.perl
> local $/;
> while (<>) {
> my $file = $_;
> while ($file =~ m/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,/g) {
> my $var = $1;
> if ($file =~ 
> s/\bDEVICE_ATTR\s*\(\s*${var}\s*,\s*\(?(\s*S_IRUGO\s*\|\s*S
> $file =~ s/\bshow_${var}\b/${var}_show/g;
> $file =~ s/\bstore_${var}\b/${var}_store/g;
> }
> }
> print $file;
> }
> 
> $ git grep --name-only -w DEVICE_ATTR | \
>   xargs perl -i dev_attr_rw_backwards.perl
> 

Ah, nice, I love perl :)

greg k-h

Re: [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW

[Greg Kroah-Hartman]

On Wed, Dec 20, 2017 at 01:24:44AM -0800, Joe Perches wrote:
> On Wed, 2017-12-20 at 10:34 +0200, Jarkko Nikula wrote:
> > On Tue, Dec 19, 2017 at 10:15:07AM -0800, Joe Perches wrote:
> > > Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.
> [] 
> > > diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
> []
> > > @@ -854,7 +854,7 @@ static ssize_t dma_op_mode_store(struct device *dev,
> > >   return size;
> > >  }
> > >  
> > > -static DEVICE_ATTR(dma_op_mode, 0644, dma_op_mode_show, 
> > > dma_op_mode_store);
> > > +static DEVICE_ATTR_RW(dma_op_mode);
> > >  
> > 
> > While I can ack this part here if it helps generic cleanup effort I
> > don't understart would it improve code readability in general? Mode 644
> > is clear and don't need any grepping but for DEVICE_ATTR_RW() I had to go
> > through all of these files in order to see what does it mean:

Yeah, 644 is "clear", but _RW() is even more clear.  Ideally I want to
get rid of all of the "non-standard" users that set random modes of
sysfs files, as we get it wrong too many times.  Using the "defaults" is
much better.

> Are you suggesting that device.h (as that is where
> DEVICE_ATTR and the other DEVICE_ATTR_ variants
> are #defined) should have better comments for the
> _ variants?
> 
> > DEVICE_ATTR_RW: include/linux/device.h
> > __ATTR_RW: include/linux/sysfs.h
> > S_IWUSR: include/uapi/linux/stat.h
> > S_IRUGO: include/linux/stat.h
> 
> btw: patch 1/4 of the series does remove the uses of
> S_ from these macros in sysfs.h and converts
> them to simple octal instead.

Why you didn't send that patch to the sysfs maintainer is a bit odd...  :)

I should be taking this whole series through my tree.  Joe, thanks for
doing this in an automated way, I've been wanting to see this done for a
long time.

thanks,

greg k-h

[PATCH] scsi: csiostor: remove unneeded DRIVER_LICENSE #define

[Greg Kroah-Hartman]

There is no need to #define the license of the driver, just put it in
the MODULE_LICENSE() line directly as a text string.

This allows tools that check that the module license matches the source
code license to work properly, as there is no need to unwind the
unneeded dereference, especially when the string is defined in a .h file
far away from the .c file it is used in.

Cc: "James E.J. Bottomley" <j...@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: Varun Prakash <va...@chelsio.com>
Reported-by: Philippe Ombredanne <pombreda...@nexb.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/scsi/csiostor/csio_init.c | 2 +-
 drivers/scsi/csiostor/csio_init.h | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/csiostor/csio_init.c 
b/drivers/scsi/csiostor/csio_init.c
index 28a9c7d706cb..abd71379bce3 100644
--- a/drivers/scsi/csiostor/csio_init.c
+++ b/drivers/scsi/csiostor/csio_init.c
@@ -1255,7 +1255,7 @@ module_init(csio_init);
 module_exit(csio_exit);
 MODULE_AUTHOR(CSIO_DRV_AUTHOR);
 MODULE_DESCRIPTION(CSIO_DRV_DESC);
-MODULE_LICENSE(CSIO_DRV_LICENSE);
+MODULE_LICENSE("Dual BSD/GPL");
 MODULE_DEVICE_TABLE(pci, csio_pci_tbl);
 MODULE_VERSION(CSIO_DRV_VERSION);
 MODULE_FIRMWARE(FW_FNAME_T5);
diff --git a/drivers/scsi/csiostor/csio_init.h 
b/drivers/scsi/csiostor/csio_init.h
index 96b31e5af91e..20244254325a 100644
--- a/drivers/scsi/csiostor/csio_init.h
+++ b/drivers/scsi/csiostor/csio_init.h
@@ -48,7 +48,6 @@
 #include "csio_hw.h"
 
 #define CSIO_DRV_AUTHOR"Chelsio Communications"
-#define CSIO_DRV_LICENSE   "Dual BSD/GPL"
 #define CSIO_DRV_DESC  "Chelsio FCoE driver"
 #define CSIO_DRV_VERSION   "1.0.0-ko"
 
-- 
2.15.0

Re: network namespace, netlink and sysfs changes for iSCSI (Re: [PATCH 0/9] use network namespace for iSCSI control interfaces)

[Greg Kroah-Hartman]

On Tue, Nov 07, 2017 at 10:01:56AM -0800, Chris Leech wrote:
> Hello,
> 
> I have this set of changes to the iSCSI control interfaces pending
> review, but seeing as it's sysfs and netlink changes there's not a lot
> of feedback from linux-scsi.
> 
> I was hoping I could get a brief review on the adding of network
> namespace support here.

Where is "here"?  I don't see any patches "here" to review :(

And no, I'm not on the scsi mailing lists :)

thanks,

greg k-h

[PATCH 4.13 41/53] genirq/cpuhotplug: Enforce affinity setting on startup of managed irqs

[Greg Kroah-Hartman]

4.13-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Gleixner <t...@linutronix.de>

commit e43b3b58548051f8809391eb7bec7a27ed3003ea upstream.

Managed interrupts can end up in a stale state on CPU hotplug. If the
interrupt is not targeting a single CPU, i.e. the affinity mask spawns
multiple CPUs then the following can happen:

After boot:

dstate:   0x01601200
IRQD_ACTIVATED
IRQD_IRQ_STARTED
IRQD_SINGLE_TARGET
IRQD_AFFINITY_SET
IRQD_AFFINITY_MANAGED
node: 0
affinity: 24-31
effectiv: 24
pending:  0

After offlining CPU 31 - 24

dstate:   0x01a31000
IRQD_IRQ_DISABLED
IRQD_IRQ_MASKED
IRQD_SINGLE_TARGET
IRQD_AFFINITY_SET
IRQD_AFFINITY_MANAGED
IRQD_MANAGED_SHUTDOWN
node: 0
affinity: 24-31
effectiv: 24
pending:  0

Now CPU 25 gets onlined again, so it should get the effective interrupt
affinity for this interruopt, but due to the x86 interrupt affinity setter
restrictions this ends up after restarting the interrupt with:

dstate:   0x01601300
IRQD_ACTIVATED
IRQD_IRQ_STARTED
IRQD_SINGLE_TARGET
IRQD_AFFINITY_SET
IRQD_SETAFFINITY_PENDING
IRQD_AFFINITY_MANAGED
node: 0
affinity: 24-31
effectiv: 24
pending:  24-31

So the interrupt is still affine to CPU 24, which was the last CPU to go
offline of that affinity set and the move to an online CPU within 24-31,
in this case 25, is pending. This mechanism is x86/ia64 specific as those
architectures cannot move interrupts from thread context and do this when
an interrupt is actually handled. So the move is set to pending.

Whats worse is that offlining CPU 25 again results in:

dstate:   0x01601300
IRQD_ACTIVATED
IRQD_IRQ_STARTED
IRQD_SINGLE_TARGET
IRQD_AFFINITY_SET
IRQD_SETAFFINITY_PENDING
IRQD_AFFINITY_MANAGED
node: 0
affinity: 24-31
effectiv: 24
pending:  24-31

This means the interrupt has not been shut down, because the outgoing CPU
is not in the effective affinity mask, but of course nothing notices that
the effective affinity mask is pointing at an offline CPU.

In the case of restarting a managed interrupt the move restriction does not
apply, so the affinity setting can be made unconditional. This needs to be
done _before_ the interrupt is started up as otherwise the condition for
moving it from thread context would not longer be fulfilled.

With that change applied onlining CPU 25 after offlining 31-24 results in:

dstate:   0x01600200
IRQD_ACTIVATED
IRQD_IRQ_STARTED
IRQD_SINGLE_TARGET
IRQD_AFFINITY_MANAGED
node: 0
affinity: 24-31
effectiv: 25
pending:

And after offlining CPU 25:

dstate:   0x01a3
IRQD_IRQ_DISABLED
IRQD_IRQ_MASKED
IRQD_SINGLE_TARGET
IRQD_AFFINITY_MANAGED
IRQD_MANAGED_SHUTDOWN
node: 0
affinity: 24-31
effectiv: 25
pending:

which is the correct and expected result.

Fixes: 761ea388e8c4 ("genirq: Handle managed irqs gracefully in irq_startup()")
Reported-by: YASUAKI ISHIMATSU <yasu.isim...@gmail.com>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: ax...@kernel.dk
Cc: linux-scsi@vger.kernel.org
Cc: Sumit Saxena <sumit.sax...@broadcom.com>
Cc: Marc Zyngier <marc.zyng...@arm.com>
Cc: m...@ellerman.id.au
Cc: Shivasharan Srikanteshwara <shivasharan.srikanteshw...@broadcom.com>
Cc: Kashyap Desai <kashyap.de...@broadcom.com>
Cc: keith.bu...@intel.com
Cc: pet...@infradead.org
Cc: Hannes Reinecke <h...@suse.de>
Cc: Christoph Hellwig <h...@lst.de>
Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1710042208400.2406@nanos
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 kernel/irq/chip.c   |2 +-
 kernel/irq/manage.c |3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -265,8 +265,8 @@ int irq_startup(struct irq_desc *desc, b
irq_setup_affinity(desc);
break;
case IRQ_STARTUP_MANAGED:
+   irq_do_set_affinity(d, aff, false);
ret = __irq_startup(desc);
-   irq_set_affinity_locked(d, aff, false);
break;
case IRQ_STARTUP_ABORT:
return 0;
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -175,6 +175,9 @@ int irq_do_set_affinity(struct irq_data
struct irq_chip *chip = irq_data_get_irq_chip(data);
int ret;
 
+   if (!chip || !chip->irq_set_affinity)
+   return -EINVAL;
+
ret = chip->irq_set_affinity(data, mask, force);
switch (ret) {
case IRQ_SET_MASK_OK:

Re: [PATCH 10/13] timer: Remove expires and data arguments from DEFINE_TIMER

[Greg Kroah-Hartman]

On Wed, Oct 04, 2017 at 04:27:04PM -0700, Kees Cook wrote:
> Drop the arguments from the macro and adjust all callers with the
> following script:
> 
>   perl -pi -e 's/DEFINE_TIMER\((.*), 0, 0\);/DEFINE_TIMER($1);/g;' \
> $(git grep DEFINE_TIMER | cut -d: -f1 | sort -u | grep -v timer.h)
> 
> Signed-off-by: Kees Cook <keesc...@chromium.org>
> Acked-by: Geert Uytterhoeven <ge...@linux-m68k.org> # for m68k parts
> ---
>  arch/arm/mach-ixp4xx/dsmg600-setup.c  | 2 +-
>  arch/arm/mach-ixp4xx/nas100d-setup.c  | 2 +-
>  arch/m68k/amiga/amisound.c| 2 +-
>  arch/m68k/mac/macboing.c  | 2 +-
>  arch/mips/mti-malta/malta-display.c   | 2 +-
>  arch/parisc/kernel/pdc_cons.c | 2 +-
>  arch/s390/mm/cmm.c| 2 +-
>  drivers/atm/idt77105.c| 4 ++--
>  drivers/atm/iphase.c  | 2 +-
>  drivers/block/ataflop.c   | 8 
>  drivers/char/dtlk.c   | 2 +-
>  drivers/char/hangcheck-timer.c| 2 +-
>  drivers/char/nwbutton.c   | 2 +-
>  drivers/char/rtc.c| 2 +-
>  drivers/input/touchscreen/s3c2410_ts.c| 2 +-
>  drivers/net/cris/eth_v10.c| 6 +++---
>  drivers/net/hamradio/yam.c| 2 +-
>  drivers/net/wireless/atmel/at76c50x-usb.c | 2 +-
>  drivers/staging/speakup/main.c| 2 +-
>  drivers/staging/speakup/synth.c   | 2 +-
>  drivers/tty/cyclades.c| 2 +-
>  drivers/tty/isicom.c  | 2 +-
>  drivers/tty/moxa.c| 2 +-
>  drivers/tty/rocket.c  | 2 +-
>  drivers/tty/vt/keyboard.c | 2 +-
>  drivers/tty/vt/vt.c   | 2 +-
>  drivers/watchdog/alim7101_wdt.c   | 2 +-
>  drivers/watchdog/machzwd.c| 2 +-
>  drivers/watchdog/mixcomwd.c   | 2 +-
>  drivers/watchdog/sbc60xxwdt.c | 2 +-
>  drivers/watchdog/sc520_wdt.c  | 2 +-
>  drivers/watchdog/via_wdt.c| 2 +-
>  drivers/watchdog/w83877f_wdt.c| 2 +-
>  drivers/xen/grant-table.c | 2 +-
>  fs/pstore/platform.c  | 2 +-
>  include/linux/timer.h | 4 ++--
>  kernel/irq/spurious.c | 2 +-
>  lib/random32.c| 2 +-
>  net/atm/mpc.c | 2 +-
>  net/decnet/dn_route.c | 2 +-
>  net/ipv6/ip6_flowlabel.c  | 2 +-
>  net/netrom/nr_loopback.c  | 2 +-
>  security/keys/gc.c| 2 +-
>  sound/oss/midibuf.c   | 2 +-
>  sound/oss/soundcard.c | 2 +-
>  sound/oss/sys_timer.c | 2 +-
>  sound/oss/uart6850.c  | 2 +-
>  47 files changed, 54 insertions(+), 54 deletions(-)

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Re: usb/storage/uas: slab-out-of-bounds in uas_probe

[Greg Kroah-Hartman]

On Fri, Sep 22, 2017 at 09:58:15AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 21, 2017 at 03:04:05PM -0400, Alan Stern wrote:
> > On Thu, 21 Sep 2017, Andrey Konovalov wrote:
> > 
> > > On Thu, Sep 21, 2017 at 6:10 PM, Greg Kroah-Hartman
> > > <gre...@linuxfoundation.org> wrote:
> > > > On Thu, Sep 21, 2017 at 05:39:05PM +0200, Andrey Konovalov wrote:
> > > >> Hi!
> > > >>
> > > >> I've got the following report while fuzzing the kernel with syzkaller.
> > > >>
> > > >> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
> > > >>
> > > >> The issue occurs when we iterate over interface altsettings, but I
> > > >> don't see the driver doing anything wrong. I might be missing
> > > >> something, or this might be an issue in USB core altsettings parsing.
> > > >
> > > >
> > > > Any chance you happen to have the descriptors that you were feeding into
> > > > the kernel at this crash?  That might help in figuring out what "went
> > > > wrong".
> > > 
> > > Here's the data that I feed into dummy_udc:
> > > 
> > > 00 00 00 00 09 02 12 00 01 34 05 80 07 09 04 6e
> > > 09 00 08 06 62 00 12 01 05 00 cb f7 71 83 04 00
> > > 05 00 ab f6 07 81 08 01
> > > 
> > > Also attaching a C reproducer (requires dummy_hcd and gadgetfs) and my 
> > > .config.
> > 
> > Why do your reproducers use an mmap'ed array for their data instead of 
> > a plain old statically allocated array?
> > 
> > Anyway, this turns out to be a genuine (and subtle!) bug in the uas
> > driver.  The uas_find_uas_alt_setting() routine in uas-detect.h returns
> > a bAlternateSetting value, but then the uas_use_uas_driver() routine
> > uses this value as an index to the altsetting array -- which it isn't.  
> > 
> > Normally this doesn't cause any problems because the the entries in the
> > array have bAlternateSetting values 0, 1, etc., so the value is equal
> > to the index.  But in your fuzzed case, that wasn't true.
> > 
> > The patch below fixes this bug, by returning a pointer to the 
> > alt-setting entry instead of either the value or the index.  Pointers 
> > are less subject to misinterpretation.
> 
> Ugh, messy, nice catch and fix, I'll go queue it up now, thanks for
> resolving this.

Oops, no, you didn't send this as a "real" patch yet, I'll wait :)

Re: usb/storage/uas: slab-out-of-bounds in uas_probe

[Greg Kroah-Hartman]

On Thu, Sep 21, 2017 at 03:04:05PM -0400, Alan Stern wrote:
> On Thu, 21 Sep 2017, Andrey Konovalov wrote:
> 
> > On Thu, Sep 21, 2017 at 6:10 PM, Greg Kroah-Hartman
> > <gre...@linuxfoundation.org> wrote:
> > > On Thu, Sep 21, 2017 at 05:39:05PM +0200, Andrey Konovalov wrote:
> > >> Hi!
> > >>
> > >> I've got the following report while fuzzing the kernel with syzkaller.
> > >>
> > >> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
> > >>
> > >> The issue occurs when we iterate over interface altsettings, but I
> > >> don't see the driver doing anything wrong. I might be missing
> > >> something, or this might be an issue in USB core altsettings parsing.
> > >
> > >
> > > Any chance you happen to have the descriptors that you were feeding into
> > > the kernel at this crash?  That might help in figuring out what "went
> > > wrong".
> > 
> > Here's the data that I feed into dummy_udc:
> > 
> > 00 00 00 00 09 02 12 00 01 34 05 80 07 09 04 6e
> > 09 00 08 06 62 00 12 01 05 00 cb f7 71 83 04 00
> > 05 00 ab f6 07 81 08 01
> > 
> > Also attaching a C reproducer (requires dummy_hcd and gadgetfs) and my 
> > .config.
> 
> Why do your reproducers use an mmap'ed array for their data instead of 
> a plain old statically allocated array?
> 
> Anyway, this turns out to be a genuine (and subtle!) bug in the uas
> driver.  The uas_find_uas_alt_setting() routine in uas-detect.h returns
> a bAlternateSetting value, but then the uas_use_uas_driver() routine
> uses this value as an index to the altsetting array -- which it isn't.  
> 
> Normally this doesn't cause any problems because the the entries in the
> array have bAlternateSetting values 0, 1, etc., so the value is equal
> to the index.  But in your fuzzed case, that wasn't true.
> 
> The patch below fixes this bug, by returning a pointer to the 
> alt-setting entry instead of either the value or the index.  Pointers 
> are less subject to misinterpretation.

Ugh, messy, nice catch and fix, I'll go queue it up now, thanks for
resolving this.

greg k-h

Re: usb/storage/uas: slab-out-of-bounds in uas_probe

[Greg Kroah-Hartman]

On Thu, Sep 21, 2017 at 05:39:05PM +0200, Andrey Konovalov wrote:
> Hi!
> 
> I've got the following report while fuzzing the kernel with syzkaller.
> 
> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
> 
> The issue occurs when we iterate over interface altsettings, but I
> don't see the driver doing anything wrong. I might be missing
> something, or this might be an issue in USB core altsettings parsing.


Any chance you happen to have the descriptors that you were feeding into
the kernel at this crash?  That might help in figuring out what "went
wrong".

thanks,

greg k-h

[PATCH 4.12 042/196] scsi: virtio_scsi: let host do exception handling

[Greg Kroah-Hartman]

4.12-stable review patch.  If anyone has any objections, please let me know.

--

From: Paolo Bonzini <pbonz...@redhat.com>

commit e72c9a2a67a6400c8ef3d01d4c461dbbbfa0e1f0 upstream.

virtio_scsi tries to do exception handling after the default 30 seconds
timeout expires.  However, it's better to let the host control the
timeout, otherwise with a heavy I/O load it is likely that an abort will
also timeout.  This leads to fatal errors like filesystems going
offline.

Disable the 'sd' timeout and allow the host to do exception handling,
following the precedent of the storvsc driver.

Hannes has a proposal to introduce timeouts in virtio, but this provides
an immediate solution for stable kernels too.

[mkp: fixed typo]

Reported-by: Douglas Miller <dougm...@linux.vnet.ibm.com>
Cc: "James E.J. Bottomley" <j...@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: Hannes Reinecke <h...@suse.de>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 drivers/scsi/virtio_scsi.c |   12 
 1 file changed, 12 insertions(+)

--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -796,6 +796,16 @@ static int virtscsi_map_queues(struct Sc
return blk_mq_virtio_map_queues(>tag_set, vscsi->vdev, 2);
 }
 
+/*
+ * The host guarantees to respond to each command, although I/O
+ * latencies might be higher than on bare metal.  Reset the timer
+ * unconditionally to give the host a chance to perform EH.
+ */
+static enum blk_eh_timer_return virtscsi_eh_timed_out(struct scsi_cmnd *scmnd)
+{
+   return BLK_EH_RESET_TIMER;
+}
+
 static struct scsi_host_template virtscsi_host_template_single = {
.module = THIS_MODULE,
.name = "Virtio SCSI HBA",
@@ -806,6 +816,7 @@ static struct scsi_host_template virtscs
.change_queue_depth = virtscsi_change_queue_depth,
.eh_abort_handler = virtscsi_abort,
.eh_device_reset_handler = virtscsi_device_reset,
+   .eh_timed_out = virtscsi_eh_timed_out,
.slave_alloc = virtscsi_device_alloc,
 
.can_queue = 1024,
@@ -826,6 +837,7 @@ static struct scsi_host_template virtscs
.change_queue_depth = virtscsi_change_queue_depth,
.eh_abort_handler = virtscsi_abort,
.eh_device_reset_handler = virtscsi_device_reset,
+   .eh_timed_out = virtscsi_eh_timed_out,
 
.can_queue = 1024,
.dma_boundary = UINT_MAX,

Re: [PATCH 1/1] scsi: ufs: changing maintainer

[Greg Kroah-Hartman (gre...@linuxfoundation.org)]

On Tue, Jul 18, 2017 at 09:15:58AM +, Prabu Thangamuthu wrote:
> As per internal decision, Joao Pinto will be maintainer for DWC UFS driver.

That's "odd", does Joao want this?  Do you want this?

thanks,

greg k-h

[PATCH 2/7] scsi: ibmvscsi_tgt: remove use of class_attrs

[Greg Kroah-Hartman]

The class_attrs pointer is going away and it's not even being used in
this driver, so just remove it entirely.

Cc: "Bryant G. Ly" <bryan...@linux.vnet.ibm.com>
Cc: Michael Cyr <mike...@linux.vnet.ibm.com>
Cc: "James E.J. Bottomley" <j...@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: <linux-scsi@vger.kernel.org>
Cc: <target-de...@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c 
b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
index d390325c99ec..b480878e3258 100644
--- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
+++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
@@ -3915,10 +3915,6 @@ static const struct target_core_fabric_ops ibmvscsis_ops 
= {
 
 static void ibmvscsis_dev_release(struct device *dev) {};
 
-static struct class_attribute ibmvscsis_class_attrs[] = {
-   __ATTR_NULL,
-};
-
 static struct device_attribute dev_attr_system_id =
__ATTR(system_id, S_IRUGO, system_id_show, NULL);
 
@@ -3938,7 +3934,6 @@ ATTRIBUTE_GROUPS(ibmvscsis_dev);
 static struct class ibmvscsis_class = {
.name   = "ibmvscsis",
.dev_release= ibmvscsis_dev_release,
-   .class_attrs= ibmvscsis_class_attrs,
.dev_groups = ibmvscsis_dev_groups,
 };
 
-- 
2.13.1

[PATCH 4.4 13/18] blk-mq: Avoid memory reclaim when remapping queues

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com>

commit 36e1f3d107867b25c616c2fd294f5a1c9d4e5d09 upstream.

While stressing memory and IO at the same time we changed SMT settings,
we were able to consistently trigger deadlocks in the mm system, which
froze the entire machine.

I think that under memory stress conditions, the large allocations
performed by blk_mq_init_rq_map may trigger a reclaim, which stalls
waiting on the block layer remmaping completion, thus deadlocking the
system.  The trace below was collected after the machine stalled,
waiting for the hotplug event completion.

The simplest fix for this is to make allocations in this path
non-reclaimable, with GFP_NOIO.  With this patch, We couldn't hit the
issue anymore.

This should apply on top of Jens's for-next branch cleanly.

Changes since v1:
  - Use GFP_NOIO instead of GFP_NOWAIT.

 Call Trace:
[c00f0160aaf0] [c00f0160ab50] 0xc00f0160ab50 (unreliable)
[c00f0160acc0] [c0016624] __switch_to+0x2e4/0x430
[c00f0160ad20] [c0b1a880] __schedule+0x310/0x9b0
[c00f0160ae00] [c0b1af68] schedule+0x48/0xc0
[c00f0160ae30] [c0b1b4b0] schedule_preempt_disabled+0x20/0x30
[c00f0160ae50] [c0b1d4fc] __mutex_lock_slowpath+0xec/0x1f0
[c00f0160aed0] [c0b1d678] mutex_lock+0x78/0xa0
[c00f0160af00] [d00019413cac] xfs_reclaim_inodes_ag+0x33c/0x380 [xfs]
[c00f0160b0b0] [d00019415164] xfs_reclaim_inodes_nr+0x54/0x70 [xfs]
[c00f0160b0f0] [d000194297f8] xfs_fs_free_cached_objects+0x38/0x60 [xfs]
[c00f0160b120] [c03172c8] super_cache_scan+0x1f8/0x210
[c00f0160b190] [c026301c] shrink_slab.part.13+0x21c/0x4c0
[c00f0160b2d0] [c0268088] shrink_zone+0x2d8/0x3c0
[c00f0160b380] [c026834c] do_try_to_free_pages+0x1dc/0x520
[c00f0160b450] [c026876c] try_to_free_pages+0xdc/0x250
[c00f0160b4e0] [c0251978] __alloc_pages_nodemask+0x868/0x10d0
[c00f0160b6f0] [c0567030] blk_mq_init_rq_map+0x160/0x380
[c00f0160b7a0] [c056758c] blk_mq_map_swqueue+0x33c/0x360
[c00f0160b820] [c0567904] blk_mq_queue_reinit+0x64/0xb0
[c00f0160b850] [c056a16c] blk_mq_queue_reinit_notify+0x19c/0x250
[c00f0160b8a0] [c00f5d38] notifier_call_chain+0x98/0x100
[c00f0160b8f0] [c00c5fb0] __cpu_notify+0x70/0xe0
[c00f0160b930] [c00c63c4] notify_prepare+0x44/0xb0
[c00f0160b9b0] [c00c52f4] cpuhp_invoke_callback+0x84/0x250
[c00f0160ba10] [c00c570c] cpuhp_up_callbacks+0x5c/0x120
[c00f0160ba60] [c00c7cb8] _cpu_up+0xf8/0x1d0
[c00f0160bac0] [c00c7eb0] do_cpu_up+0x120/0x150
[c00f0160bb40] [c06fe024] cpu_subsys_online+0x64/0xe0
[c00f0160bb90] [c06f5124] device_online+0xb4/0x120
[c00f0160bbd0] [c06f5244] online_store+0xb4/0xc0
[c00f0160bc20] [c06f0a68] dev_attr_store+0x68/0xa0
[c00f0160bc60] [c03ccc30] sysfs_kf_write+0x80/0xb0
[c00f0160bca0] [c03cbabc] kernfs_fop_write+0x17c/0x250
[c00f0160bcf0] [c030fe6c] __vfs_write+0x6c/0x1e0
[c00f0160bd90] [c0311490] vfs_write+0xd0/0x270
[c00f0160bde0] [c03131fc] SyS_write+0x6c/0x110
[c00f0160be30] [c0009204] system_call+0x38/0xec

Signed-off-by: Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com>
Cc: Brian King <brk...@linux.vnet.ibm.com>
Cc: Douglas Miller <dougm...@linux.vnet.ibm.com>
Cc: linux-bl...@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Jens Axboe <ax...@fb.com>
Signed-off-by: Sumit Semwal <sumit.sem...@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 block/blk-mq.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1470,7 +1470,7 @@ static struct blk_mq_tags *blk_mq_init_r
INIT_LIST_HEAD(>page_list);
 
tags->rqs = kzalloc_node(set->queue_depth * sizeof(struct request *),
-GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY,
+GFP_NOIO | __GFP_NOWARN | __GFP_NORETRY,
 set->numa_node);
if (!tags->rqs) {
blk_mq_free_tags(tags);
@@ -1496,7 +1496,7 @@ static struct blk_mq_tags *blk_mq_init_r
 
do {
page = alloc_pages_node(set->numa_node,
-   GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY | 
__GFP_ZERO,
+   GFP_NOIO | __GFP_NOWARN | __GFP_NORETRY | 
__GFP_ZERO,
this_order);
if (page)
break;
@@ -1517,7 +1517,7 @@ static struct blk_mq_tags *blk_mq_init_r
 *

[PATCH 4.9 26/31] blk-mq: Avoid memory reclaim when remapping queues

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com>

commit 36e1f3d107867b25c616c2fd294f5a1c9d4e5d09 upstream.

While stressing memory and IO at the same time we changed SMT settings,
we were able to consistently trigger deadlocks in the mm system, which
froze the entire machine.

I think that under memory stress conditions, the large allocations
performed by blk_mq_init_rq_map may trigger a reclaim, which stalls
waiting on the block layer remmaping completion, thus deadlocking the
system.  The trace below was collected after the machine stalled,
waiting for the hotplug event completion.

The simplest fix for this is to make allocations in this path
non-reclaimable, with GFP_NOIO.  With this patch, We couldn't hit the
issue anymore.

This should apply on top of Jens's for-next branch cleanly.

Changes since v1:
  - Use GFP_NOIO instead of GFP_NOWAIT.

 Call Trace:
[c00f0160aaf0] [c00f0160ab50] 0xc00f0160ab50 (unreliable)
[c00f0160acc0] [c0016624] __switch_to+0x2e4/0x430
[c00f0160ad20] [c0b1a880] __schedule+0x310/0x9b0
[c00f0160ae00] [c0b1af68] schedule+0x48/0xc0
[c00f0160ae30] [c0b1b4b0] schedule_preempt_disabled+0x20/0x30
[c00f0160ae50] [c0b1d4fc] __mutex_lock_slowpath+0xec/0x1f0
[c00f0160aed0] [c0b1d678] mutex_lock+0x78/0xa0
[c00f0160af00] [d00019413cac] xfs_reclaim_inodes_ag+0x33c/0x380 [xfs]
[c00f0160b0b0] [d00019415164] xfs_reclaim_inodes_nr+0x54/0x70 [xfs]
[c00f0160b0f0] [d000194297f8] xfs_fs_free_cached_objects+0x38/0x60 [xfs]
[c00f0160b120] [c03172c8] super_cache_scan+0x1f8/0x210
[c00f0160b190] [c026301c] shrink_slab.part.13+0x21c/0x4c0
[c00f0160b2d0] [c0268088] shrink_zone+0x2d8/0x3c0
[c00f0160b380] [c026834c] do_try_to_free_pages+0x1dc/0x520
[c00f0160b450] [c026876c] try_to_free_pages+0xdc/0x250
[c00f0160b4e0] [c0251978] __alloc_pages_nodemask+0x868/0x10d0
[c00f0160b6f0] [c0567030] blk_mq_init_rq_map+0x160/0x380
[c00f0160b7a0] [c056758c] blk_mq_map_swqueue+0x33c/0x360
[c00f0160b820] [c0567904] blk_mq_queue_reinit+0x64/0xb0
[c00f0160b850] [c056a16c] blk_mq_queue_reinit_notify+0x19c/0x250
[c00f0160b8a0] [c00f5d38] notifier_call_chain+0x98/0x100
[c00f0160b8f0] [c00c5fb0] __cpu_notify+0x70/0xe0
[c00f0160b930] [c00c63c4] notify_prepare+0x44/0xb0
[c00f0160b9b0] [c00c52f4] cpuhp_invoke_callback+0x84/0x250
[c00f0160ba10] [c00c570c] cpuhp_up_callbacks+0x5c/0x120
[c00f0160ba60] [c00c7cb8] _cpu_up+0xf8/0x1d0
[c00f0160bac0] [c00c7eb0] do_cpu_up+0x120/0x150
[c00f0160bb40] [c06fe024] cpu_subsys_online+0x64/0xe0
[c00f0160bb90] [c06f5124] device_online+0xb4/0x120
[c00f0160bbd0] [c06f5244] online_store+0xb4/0xc0
[c00f0160bc20] [c06f0a68] dev_attr_store+0x68/0xa0
[c00f0160bc60] [c03ccc30] sysfs_kf_write+0x80/0xb0
[c00f0160bca0] [c03cbabc] kernfs_fop_write+0x17c/0x250
[c00f0160bcf0] [c030fe6c] __vfs_write+0x6c/0x1e0
[c00f0160bd90] [c0311490] vfs_write+0xd0/0x270
[c00f0160bde0] [c03131fc] SyS_write+0x6c/0x110
[c00f0160be30] [c0009204] system_call+0x38/0xec

Signed-off-by: Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com>
Cc: Brian King <brk...@linux.vnet.ibm.com>
Cc: Douglas Miller <dougm...@linux.vnet.ibm.com>
Cc: linux-bl...@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Jens Axboe <ax...@fb.com>
Signed-off-by: Sumit Semwal <sumit.sem...@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 block/blk-mq.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1474,7 +1474,7 @@ static struct blk_mq_tags *blk_mq_init_r
INIT_LIST_HEAD(>page_list);
 
tags->rqs = kzalloc_node(set->queue_depth * sizeof(struct request *),
-GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY,
+GFP_NOIO | __GFP_NOWARN | __GFP_NORETRY,
 set->numa_node);
if (!tags->rqs) {
blk_mq_free_tags(tags);
@@ -1500,7 +1500,7 @@ static struct blk_mq_tags *blk_mq_init_r
 
do {
page = alloc_pages_node(set->numa_node,
-   GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY | 
__GFP_ZERO,
+   GFP_NOIO | __GFP_NOWARN | __GFP_NORETRY | 
__GFP_ZERO,
this_order);
if (page)
break;
@@ -1521,7 +1521,7 @@ static struct blk_mq_tags *blk_mq_init_r
 *

Re: [PATCH] scsi: mpt3sas: fix hang on ata passthrough command (try 2)

[Greg Kroah-Hartman]

On Fri, Mar 31, 2017 at 04:38:57PM -0400, Joe Korty wrote:
> scsi: mpt3sas: fix hang on ata passthrough commands
> 
> commit 16236802bfecb1082144a48b7d6fa60997824662 upstream, in v4.9 in 
> linux-stable.
> commit ffb58456589443ca572221fabbdef3db8483a779 upstream, in master.
> 
> Please backport the above mentioned v4.9 version of the commit into
> v4.4.  It fixes a 'inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage'
> bug introduced when two other mpt3sas patches were backported into
> v4.4.28.

Ok, now done.

> In v4.4.28, a call to scsi_internal_device_unblock() was added
> to the mpt3sas driver's interrupt level routine, but that service
> expects to be called only from base level, so not all of its uses
> of spin locks are protected from interrupts.  Thus self deadlock
> is possible.  In this case, the 'spin_lock(>lock)' in
> __blk_mq_run_hw_queue() is the immediate cause of this lockdep
> assertion.  This happens on the first use of the mpt3sas driver.
> 
> [   28.340336] =
> [   28.344799] [ INFO: inconsistent lock state ]
> [   28.349229] 4.4.53 #2 Not tainted
> [   28.352566] -
> [   28.357004] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> [   28.363019] swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
> [   28.368202]  (&(>lock)->rlock){?.+...}, at: [] 
> __blk_mq_run_hw_queue+0x172/0x3b0
> [   28.377872] {HARDIRQ-ON-W} state was registered at:
> [   28.382829]   [] __lock_acquire+0x8e4/0xe80
> [   28.388612]   [] lock_acquire+0xde/0x310
> [   28.390151]   [] _raw_spin_lock+0x3b/0x50
> [   28.390154]   [] __blk_mq_run_hw_queue+0x246/0x3b0
> [   28.390157]   [] blk_mq_run_hw_queue+0x65/0xf0
> [   28.390159]   [] blk_sq_make_request+0x24d/0x740
> [   28.390163]   [] generic_make_request+0xfa/0x190
> [   28.390166]   [] submit_bio+0x7f/0x160
> [   28.390172]   [] submit_bh_wbc+0x13e/0x180
> [   28.390175]   [] submit_bh+0x12/0x20
> [   28.390179]   [] __ext4_get_inode_loc+0x21c/0x590
> [   28.390181]   [] ext4_iget+0x88/0xc30
> [   28.390183]   [] ext4_fill_super+0x1cc5/0x3660
> [   28.390187]   [] mount_bdev+0x1b5/0x200
> [   28.390190]   [] ext4_mount+0x15/0x20
> [   28.390193]   [] mount_fs+0x43/0x170
> [   28.390196]   [] vfs_kern_mount+0x76/0x160
> [   28.390198]   [] do_mount+0x263/0xf40
> [   28.390200]   [] SyS_mount+0x7b/0xc0
> [   28.390204]   [] do_mount_root+0x1e/0x97
> [   28.390206]   [] mount_block_root+0x10f/0x24b
> [   28.390208]   [] mount_root+0xf6/0x101
> [   28.390210]   [] prepare_namespace+0x170/0x1a9
> [   28.390213]   [] kernel_init_freeable+0x254/0x26b
> [   28.390215]   [] kernel_init+0xe/0xe0
> [   28.390218]   [] ret_from_fork+0x3f/0x70
> [   28.390219] irq event stamp: 482812
> [   28.390223] hardirqs last  enabled at (482809): [] 
> default_idle+0x2c/0x240
> [   28.390226] hardirqs last disabled at (482810): [] 
> common_interrupt+0x87/0x8c
> [   28.390229] softirqs last  enabled at (482812): [] 
> _local_bh_enable+0x21/0x50
> [   28.390231] softirqs last disabled at (482811): [] 
> irq_enter+0x4b/0x70
> [   28.390232] 
> other info that might help us debug this:
> [   28.390233]  Possible unsafe locking scenario:
> 
> [   28.390233]CPU0
> [   28.390234]
> [   28.390235]   lock(&(>lock)->rlock);
> [   28.390236]   
> [   28.390237] lock(&(>lock)->rlock);
> [   28.390238] 
>  *** DEADLOCK ***
> 
> [   28.390238] no locks held by swapper/0/0.
> [   28.390239] 
> stack backtrace:
> [   28.390241] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.53 #2
> [   28.390242] Hardware name: Supermicro H8QG6/H8QG6, BIOS 3.0b   
> 02/01/2013
> [   28.390246]   88021fc03858 8155ba95 
> 0001
> [   28.390249]  0003 82a17500 83200800 
> 88021fc038a8
> [   28.390252]  810c9cdf   
> 0001
> [   28.390253] Call Trace:
> [   28.390257][] dump_stack+0x89/0xd4
> [   28.390260]  [] print_usage_bug+0x23f/0x300
> [   28.390263]  [] mark_lock+0x37d/0x690
> [   28.390266]  [] ? trace_hardirqs_off+0xd/0x10
> [   28.390268]  [] __lock_acquire+0x96e/0xe80
> [   28.390272]  [] ? check_unmap+0x3df/0x970
> [   28.390275]  [] ? radix_tree_delete_item+0xb6/0x110
> [   28.390278]  [] lock_acquire+0xde/0x310
> [   28.390281]  [] ? __blk_mq_run_hw_queue+0x172/0x3b0
> [   28.390284]  [] _raw_spin_lock+0x3b/0x50
> [   28.390286]  [] ? __blk_mq_run_hw_queue+0x172/0x3b0
> [   28.390288]  [] __blk_mq_run_hw_queue+0x172/0x3b0
> [   28.390293]  [] ? _scsih_io_done+0x48/0xa60
> [   28.390296]  [] blk_mq_run_hw_queue+0x65/0xf0
> [   28.390298]  [] ? __lock_acquire+0x666/0xe80
> [   28.390301]  [] blk_mq_start_stopped_hw_queues+0x63/0x80
> [   28.390304]  [] scsi_internal_device_unblock+0x4b/0xa0
> [   28.390307]  [] _scsih_io_done+0x115/0xa60
> [   28.390310]  [] ? __lock_acquire+0x666/0xe80
> [   28.390313]  [] _base_interrupt+0x1e8/0xb90
> [   28.390317]  [] ? debug_smp_processor_id+0x17/0x20
> [   

Re: [PATCH] scsi: mpt3sas: fix hang on ata passthrough commands

[Greg Kroah-Hartman]

On Fri, Mar 31, 2017 at 02:10:29PM -0400, Joe Korty wrote:
> On Fri, Mar 31, 2017 at 04:50:52PM +0200, Greg Kroah-Hartman wrote:
> > A: Because it messes up the order in which people normally read text.
> > Q: Why is top-posting such a bad thing?
> > A: Top-posting.
> > Q: What is the most annoying thing in e-mail?
> > 
> > A: No.
> > Q: Should I include quotations after my reply?
> > 
> > 
> > http://daringfireball.net/2007/07/on_top
> > 
> > On Fri, Mar 31, 2017 at 10:16:47AM -0400, Joe Korty wrote:
> > > Hi Greg,
> > > This patch is not yet in 4.4.
> > 
> > What patch is that?  I can't find a git commit id here at all :(
> > 
> > > It is in 4.9 and upstream.  No one has submitted it to you before this
> > > email.  I only discovered the need for it because lockdep complains
> > > when it is missing.  I do not know how it was missed; perhaps there is
> > > a reason rather than it being missed by accident. Others in the know
> > > can comment if they like.
> > 
> > You need to say what you want to have happen for a stable patch, you did
> > read Documenation/stable_kernel_rules.txt, right?
> > 
> > still confused,
> > 
> > greg k-h
> 
> 
> Hi Greg,
> The patch is one that has already been backported into 4.9,
> and as such I assumed it was already in a format acceptable
> for submission.
> 
> 4.4 is the only additional branch that needs this patch,
> and there it is needed only because in 4.4.28 two other
> mpt3sas patches had been backported.  Those two patches
> introduced the lock dependency problem that this, the
> third patch, fixes.
> 
> In summary, either all three patches should be backported,
> or none should be backported.  Porting just two is wrong.

What patches?  Please start over, resend the email in a format that can
be understand as to what commits you want added to what stable kernel
tree. As it is, I still have no clue...

greg k-h

Re: [PATCH] scsi: mpt3sas: fix hang on ata passthrough commands

[Greg Kroah-Hartman]

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?


http://daringfireball.net/2007/07/on_top

On Fri, Mar 31, 2017 at 10:16:47AM -0400, Joe Korty wrote:
> Hi Greg,
> This patch is not yet in 4.4.

What patch is that?  I can't find a git commit id here at all :(

> It is in 4.9 and upstream.  No one has submitted it to you before this
> email.  I only discovered the need for it because lockdep complains
> when it is missing.  I do not know how it was missed; perhaps there is
> a reason rather than it being missed by accident. Others in the know
> can comment if they like.

You need to say what you want to have happen for a stable patch, you did
read Documenation/stable_kernel_rules.txt, right?

still confused,

greg k-h

Re: [PATCH] scsi: mpt3sas: fix hang on ata passthrough commands

[Greg Kroah-Hartman]

On Fri, Mar 31, 2017 at 09:50:30AM -0400, Joe Korty wrote:
> [PATCH] scsi: mpt3sas: fix hang on ata passthrough commands
> 
> commit 16236802bfecb1082144a48b7d6fa60997824662 upstream
> commit ffb58456589443ca572221fabbdef3db8483a779 upstream
> 
> Lockdep complains that the base level-only hctx->lock
> is being grabbed from interrupt level, at the time the
> mpt3sas driver initializes.  This is a result of two
> of three tightly interconnected mpt3sas bugfix patches
> having been backported into 4.4.  The previously two ported
> patches are:
> 
> > From: Andrey Grodzovsky <andrey2...@gmail.com>
> > Date: Thu, 10 Nov 2016 09:35:27 -0500
> > Subject: [PATCH] scsi: mpt3sas: Fix secure erase premature termination
> > Git-Commit: c1ed47e76d13cafbc645792ca184331b3123
>   
> > From: Suganath Prabu S <suganath-prabu.subram...@broadcom.com>
> > Date: Thu, 17 Nov 2016 16:15:58 +0530
> > Subject: [PATCH] scsi: mpt3sas: Unblock device after controller reset
> > Git-Commit: 6eddf5c993dd9bf4efcf2509e4ca633b9441a66a
> 
> The missing third patch is attached below.
> 
> Signed-off-by: Joe Korty <joe.ko...@ccur.com>
> 
> 
> > From: James Bottomley <james.bottom...@hansenpartnership.com>
> > Date: Sun, 1 Jan 2017 09:39:24 -0800
> > Subject: [PATCH] scsi: mpt3sas: fix hang on ata passthrough commands
> > Git-Commit: 16236802bfecb1082144a48b7d6fa60997824662
> 
> commit ffb58456589443ca572221fabbdef3db8483a779 upstream.
> 
> mpt3sas has a firmware failure where it can only handle one pass through
> ATA command at a time.  If another comes in, contrary to the SAT
> standard, it will hang until the first one completes (causing long
> commands like secure erase to timeout).  The original fix was to block
> the device when an ATA command came in, but this caused a regression
> with
> 
> commit 669f044170d8933c3d66d231b69ea97cb8447338
> Author: Bart Van Assche <bart.vanass...@sandisk.com>
> Date:   Tue Nov 22 16:17:13 2016 -0800
> 
> scsi: srp_transport: Move queuecommand() wait code to SCSI core
> 
> So fix the original fix of the secure erase timeout by properly
> returning SAM_STAT_BUSY like the SAT recommends.  The original patch
> also had a concurrency problem since scsih_qcmd is lockless at that
> point (this is fixed by using atomic bitops to set and test the flag).
> 
> [mkp: addressed feedback wrt. test_bit and fixed whitespace]
> 
> Fixes: 18f6084a989ba1b (mpt3sas: Fix secure erase premature termination)
> Signed-off-by: James Bottomley <james.bottom...@hansenpartnership.com>
> Acked-by: Sreekanth Reddy <sreekanth.re...@broadcom.com>
> Reviewed-by: Christoph Hellwig <h...@lst.de>
> Reported-by: Ingo Molnar <mi...@kernel.org>
> Tested-by: Ingo Molnar <mi...@kernel.org>
> Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

I signed off on this patch?  When?  Where?

totall confused here,

greg k-h

Re: [RFC v2 00/20] Replace PCI pool by DMA pool API

[Greg Kroah-Hartman]

On Sat, Feb 18, 2017 at 09:35:36AM +0100, Romain Perier wrote:
> The current PCI pool API are simple macro functions direct expanded to
> the appropriated dma pool functions. The prototypes are almost the same
> and semantically, they are very similar. I propose to use the DMA pool
> API directly and get rid of the old API.
> 
> This set of patches, replaces the old API by the dma pool API, adds
> support to warn about this old API in checkpath.pl and remove the
> defines.

Why is this a "RFC" series?  Personally, I never apply those as it
implies that the author doesn't think they are ready to be merged :)

thanks,

greg k-h

Re: aacraid: kernel: AAC: Host adapter dead -1 (bisected)

[Greg Kroah-Hartman]

On Fri, Feb 10, 2017 at 01:45:06PM +0300, Andrey Melnikov wrote:
> Cc: linux-scsi@vger.kernel.org
> 
> 2017-02-10 13:24 GMT+03:00 Greg Kroah-Hartman <gre...@linuxfoundation.org>:
> > On Fri, Feb 10, 2017 at 02:25:26AM +0300, Andrey Jr. Melnikov wrote:
> >> In article <201701151205.37563.a.miskiew...@gmail.com> you wrote:
> >> > Newsgroups: gmane.linux.kernel
> >>
> >>
> >> > Hi.
> >>
> >> > There is a bug with handling of adaptec raid cards (in my case it is 
> >> > Adaptec
> >> > 3405) where kernel logs hundreds of "AAC: Host adapter dead -1" messages.
> >>
> >> > Bug was reported previously on lkml but there was no progres in solving 
> >> > it.
> >>
> >> > There is also bugzilla entry:
> >> > https://bugzilla.kernel.org/show_bug.cgi?id=151661
> >>
> >> > I've bisected that to commit bellow and indeed, reverting it from kernel 
> >> > 4.9.3
> >> > makes messages go away.
> >>
> >>
> >> Don't try to switch Adaptec 3405/3805 RAID cards to MSI-X interrupt mode.
> >> Fix https://bugzilla.kernel.org/show_bug.cgi?id=151661
> >>
> >> Signed-off-by: Andrey Jr. Melnikov <temnota...@gmail.com>
> >>
> >> ---
> >>
> >> diff --git a/drivers/scsi/aacraid/aacraid.h 
> >> b/drivers/scsi/aacraid/aacraid.h
> >> index 969c312de1be..2ad8403dea40 100644
> >> --- a/drivers/scsi/aacraid/aacraid.h
> >> +++ b/drivers/scsi/aacraid/aacraid.h
> >
> > 
> >
> > Why are you sending this to me and not the scsi developers who can
> > actually do something with this patch?
> 
> Bug in bugzilla open half year ago, microsemi maintainer slowly read
> his fine docs about his hardware, broken driver fills our log with
> useless messages every 10 seconds.
> So, make decision - apply this patch to stable 4.9.x/4.4.x tree or
> revert commit 78cbccd3bd683c295a44af8050797dc4a41376ff from it.

I don't understand, that's not how the stable kernels work, please read
Documentation/stable_kernel_rules.txt for how the process works.  Please
get a patch accepted into Linus's tree and then we will be glad to apply
it to the stable kernel trees.

thanks,

greg k-h

Re: [PATCH 5/8] linux: drop __bitwise__ everywhere

[Greg Kroah-Hartman]

On Thu, Dec 15, 2016 at 07:15:20AM +0200, Michael S. Tsirkin wrote:
> __bitwise__ used to mean "yes, please enable sparse checks
> unconditionally", but now that we dropped __CHECK_ENDIAN__
> __bitwise is exactly the same.
> There aren't many users, replace it by __bitwise everywhere.
> 
> Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
> ---
>  arch/arm/plat-samsung/include/plat/gpio-cfg.h| 2 +-
>  drivers/md/dm-cache-block-types.h| 6 +++---
>  drivers/net/ethernet/sun/sunhme.h| 2 +-
>  drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 4 ++--
>  include/linux/mmzone.h   | 2 +-
>  include/linux/serial_core.h  | 4 ++--
>  include/linux/types.h| 4 ++--
>  include/scsi/iscsi_proto.h   | 2 +-
>  include/target/target_core_base.h| 2 +-
>  include/uapi/linux/virtio_types.h| 6 +++---
>  net/ieee802154/6lowpan/6lowpan_i.h   | 2 +-
>  net/mac80211/ieee80211_i.h   | 4 ++--
>  12 files changed, 20 insertions(+), 20 deletions(-)

for include/linux/serial_core.h:

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
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: version 3.18.44 to 3.18.45 introduced a bug in "drivers/scsi/megaraid/megaraid_sas_base.c"

[Greg Kroah-Hartman]

On Tue, Dec 13, 2016 at 08:43:41AM -0800, James Bottomley wrote:
> On Tue, 2016-12-13 at 08:33 -0800, Randy Dunlap wrote:
> > On 12/13/16 08:30, Greg Kroah-Hartman wrote:
> > > I don't maintain 3.18-stable :)
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > > 
> > 
> > Thanks. My bad.
> > 
> > adding Sasha.
> 
> This was all covered here:
> 
> https://www.spinics.net/lists/stable/msg150608.html
> 
> How did it get missed, and what should the process be?

I don't know how that got missed, did the "fixup" patch never make it
into 3.18-stable?  I know Sasha has been slow on that kernel, and it's
about to go end-of-life, so perhaps he's just releasing them on a slower
cycle at the moment...

thanks,

greg k-h
--
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: version 3.18.44 to 3.18.45 introduced a bug in "drivers/scsi/megaraid/megaraid_sas_base.c"

[Greg Kroah-Hartman]

On Tue, Dec 13, 2016 at 08:08:27AM -0800, Randy Dunlap wrote:
> [adding other lists + gregkh]
> 
> 
> On 12/13/16 02:56, Dashi DS1 Cao wrote:
> > --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> > +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> > @@ -1614,16 +1614,13 @@ megasas_queue_command(struct Scsi_Host *shost, 
> > struct scsi_cmnd *scmd)
> > goto out_done;
> > }
> > 
> > -   switch (scmd->cmnd[0]) {
> > -   case SYNCHRONIZE_CACHE:
> > -   /*
> > -* FW takes care of flush cache on its own
> > -* No need to send it down
> > -*/
> > +   /*
> > +* FW takes care of flush cache on its own for Virtual Disk.
> > +* No need to send it down for VD. For JBOD send SYNCHRONIZE_CACHE 
> > to FW.
> > +*/
> > +   if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && 
> > MEGASAS_IS_LOGICAL(scmd)) {
> > scmd->result = DID_OK << 16;
> > goto out_done;
> > -   default:
> > -   break;
> > }
> > 
> > if (instance->instancet->build_and_issue_cmd(instance, scmd)) {
> > 
> > MEGASAS_IS_LOGICAL is defined to be a macro with '?' operator, which has a 
> > lower precedence than '&&'.
> > The macro should have been defined as:
> > --- a/drivers/scsi/megaraid/megaraid_sas.h
> > +++ b/drivers/scsi/megaraid/megaraid_sas.h
> > @@ -1823,7 +1823,7 @@ struct megasas_instance_template {
> >  };
> > 
> >  #define MEGASAS_IS_LOGICAL(scp)
> > \
> > -   (scp->device->channel < MEGASAS_MAX_PD_CHANNELS) ? 0 : 1
> > +   ((scp->device->channel < MEGASAS_MAX_PD_CHANNELS) ? 0 : 1)
> > 
> >  #define MEGASAS_DEV_INDEX(inst, scp)   \
> > ((scp->device->channel % 2) * MEGASAS_MAX_DEV_PER_CHANNEL) +\
> > 
> > Dashi Cao
> > 

I don't maintain 3.18-stable :)

thanks,

greg k-h
--
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] linux/types.h: enable endian checks for all sparse builds

[Greg Kroah-Hartman]

On Thu, Dec 08, 2016 at 06:38:11AM +, Bart Van Assche wrote:
> On 12/07/16 21:54, Michael S. Tsirkin wrote:
> > On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote:
> >> Additionally, there are notable exceptions to the rule that most drivers
> >> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it
> >> would remain possible to check such drivers with sparse without enabling
> >> endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__
> >> into e.g. #ifndef __DONT_CHECK_ENDIAN__?
> >
> > The right thing is probably just to fix these, isn't it?
> > Until then, why not just ignore the warnings?
> 
> Neither option is realistic. With endian-checking enabled the qla2xxx 
> driver triggers so many warnings that it becomes a real challenge to 
> filter the non-endian warnings out manually:
> 
> $ for f in "" CF=-D__CHECK_ENDIAN__; do make M=drivers/scsi/qla2xxx C=2\
>  $f |  -c ': warning:'; done
> 4
> 752
> 
> If you think it would be easy to fix the endian warnings triggered by 
> the qla2xxx driver, you are welcome to try to fix these.

Please don't let one crappy, obviously broken, driver prevent this good
change from happening which will help ensure that the rest of the kernel
(i.e. 99% of it) can be easily tested and fixed for endian issues.

Sounds like you should just fix the driver up if it has so many
problems, and it annoys you so much that you have to filter out some
warnings to see the others :)

thanks,

greg k-h
--
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.8 11/37] scsi: mpt3sas: Fix secure erase premature termination

[Greg Kroah-Hartman]

On Wed, Nov 30, 2016 at 11:49:56AM -0500, Martin K. Petersen wrote:
> >>>>> "Greg" == Greg Kroah-Hartman <gre...@linuxfoundation.org> writes:
> 
> Greg,
> 
> Greg> From: Andrey Grodzovsky <andrey2...@gmail.com>
> 
> Greg> commit 18f6084a989ba1b38702f9af37a2e4049a924be6 upstream.
> 
> Please also queue 7ff723ad0f87 ("scsi: mpt3sas: Unblock device after
> controller reset") which just hit Linus' tree. It's a bug fix for the
> patch above.

Now queued up, thanks.

greg k-h
--
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 4.4 09/21] scsi: mpt3sas: Fix secure erase premature termination

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Andrey Grodzovsky <andrey2...@gmail.com>

commit 18f6084a989ba1b38702f9af37a2e4049a924be6 upstream.

This is a work around for a bug with LSI Fusion MPT SAS2 when perfoming
secure erase. Due to the very long time the operation takes, commands
issued during the erase will time out and will trigger execution of the
abort hook. Even though the abort hook is called for the specific
command which timed out, this leads to entire device halt
(scsi_state terminated) and premature termination of the secure erase.

Set device state to busy while ATA passthrough commands are in progress.

[mkp: hand applied to 4.9/scsi-fixes, tweaked patch description]

Signed-off-by: Andrey Grodzovsky <andrey2...@gmail.com>
Acked-by: Sreekanth Reddy <sreekanth.re...@broadcom.com>
Cc: <linux-scsi@vger.kernel.org>
Cc: Sathya Prakash <sathya.prak...@broadcom.com>
Cc: Chaitra P B <chaitra.basa...@broadcom.com>
Cc: Suganath Prabu Subramani <suganath-prabu.subram...@broadcom.com>
Cc: Sreekanth Reddy <sreekanth.re...@broadcom.com>
Cc: Hannes Reinecke <h...@suse.de>
Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c |   15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -3831,7 +3831,10 @@ _scsih_eedp_error_handling(struct scsi_c
SAM_STAT_CHECK_CONDITION;
 }
 
-
+static inline bool ata_12_16_cmd(struct scsi_cmnd *scmd)
+{
+   return (scmd->cmnd[0] == ATA_12 || scmd->cmnd[0] == ATA_16);
+}
 
 /**
  * scsih_qcmd - main scsi request entry point
@@ -3859,6 +3862,13 @@ scsih_qcmd(struct Scsi_Host *shost, stru
if (ioc->logging_level & MPT_DEBUG_SCSI)
scsi_print_command(scmd);
 
+   /*
+* Lock the device for any subsequent command until command is
+* done.
+*/
+   if (ata_12_16_cmd(scmd))
+   scsi_internal_device_block(scmd->device);
+
sas_device_priv_data = scmd->device->hostdata;
if (!sas_device_priv_data || !sas_device_priv_data->sas_target) {
scmd->result = DID_NO_CONNECT << 16;
@@ -4431,6 +4441,9 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *i
if (scmd == NULL)
return 1;
 
+   if (ata_12_16_cmd(scmd))
+   scsi_internal_device_unblock(scmd->device, SDEV_RUNNING);
+
mpi_request = mpt3sas_base_get_msg_frame(ioc, smid);
 
if (mpi_reply == NULL) {


--
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 4.8 11/37] scsi: mpt3sas: Fix secure erase premature termination

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Andrey Grodzovsky <andrey2...@gmail.com>

commit 18f6084a989ba1b38702f9af37a2e4049a924be6 upstream.

This is a work around for a bug with LSI Fusion MPT SAS2 when perfoming
secure erase. Due to the very long time the operation takes, commands
issued during the erase will time out and will trigger execution of the
abort hook. Even though the abort hook is called for the specific
command which timed out, this leads to entire device halt
(scsi_state terminated) and premature termination of the secure erase.

Set device state to busy while ATA passthrough commands are in progress.

[mkp: hand applied to 4.9/scsi-fixes, tweaked patch description]

Signed-off-by: Andrey Grodzovsky <andrey2...@gmail.com>
Acked-by: Sreekanth Reddy <sreekanth.re...@broadcom.com>
Cc: <linux-scsi@vger.kernel.org>
Cc: Sathya Prakash <sathya.prak...@broadcom.com>
Cc: Chaitra P B <chaitra.basa...@broadcom.com>
Cc: Suganath Prabu Subramani <suganath-prabu.subram...@broadcom.com>
Cc: Sreekanth Reddy <sreekanth.re...@broadcom.com>
Cc: Hannes Reinecke <h...@suse.de>
Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c |   15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -4019,7 +4019,10 @@ _scsih_eedp_error_handling(struct scsi_c
SAM_STAT_CHECK_CONDITION;
 }
 
-
+static inline bool ata_12_16_cmd(struct scsi_cmnd *scmd)
+{
+   return (scmd->cmnd[0] == ATA_12 || scmd->cmnd[0] == ATA_16);
+}
 
 /**
  * scsih_qcmd - main scsi request entry point
@@ -4047,6 +4050,13 @@ scsih_qcmd(struct Scsi_Host *shost, stru
if (ioc->logging_level & MPT_DEBUG_SCSI)
scsi_print_command(scmd);
 
+   /*
+* Lock the device for any subsequent command until command is
+* done.
+*/
+   if (ata_12_16_cmd(scmd))
+   scsi_internal_device_block(scmd->device);
+
sas_device_priv_data = scmd->device->hostdata;
if (!sas_device_priv_data || !sas_device_priv_data->sas_target) {
scmd->result = DID_NO_CONNECT << 16;
@@ -4622,6 +4632,9 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *i
if (scmd == NULL)
return 1;
 
+   if (ata_12_16_cmd(scmd))
+   scsi_internal_device_unblock(scmd->device, SDEV_RUNNING);
+
mpi_request = mpt3sas_base_get_msg_frame(ioc, smid);
 
if (mpi_reply == NULL) {


--
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 v6 0/9] Replay Protected Memory Block (RPMB) subsystem

[Greg Kroah-Hartman]

On Mon, Sep 19, 2016 at 12:17:48PM +, Winkler, Tomas wrote:
> \
> > Subject: [PATCH v6 0/9] Replay Protected Memory Block (RPMB) subsystem
> > 
> > 
> > Few storage technologies such is EMMC, UFS, and NVMe support RPMB
> > hardware partition with common protocol and frame layout.
> > The RPMB partition cannot be accessed via standard block layer, but by a set
> > of specific commands: WRITE, READ, GET_WRITE_COUNTER, and
> > PROGRAM_KEY.
> > Such a partition provides authenticated and replay protected access, hence
> > suitable as a secure storage.
> > 
> > The RPMB layer aims to provide in-kernel API for Trusted Execution
> > Environment (TEE) devices that are capable to securely compute block frame
> > signature. In case a TEE device wish to store a replay protected data, it
> > creates an RPMB frame with requested data and computes HMAC of the
> > frame, then it requests the storage device via RPMB layer to store the data.
> > 
> > The layer provides two APIs, for rpmb_req_cmd() for issuing one of RPMB
> > specific commands and rpmb_seq_cmd() for issuing of raw RPMB protocol
> > frames,  which is close to the functionality provided by emmc multi ioctl
> > interface.
> > 
> > A TEE driver can claim the RPMB interface, for example, via
> > class_interface_register ().
> > 
> > A storage device registers its RPMB hardware (eMMC) partition or RPMB W-
> > LUN (UFS) with the RPMB layer providing an implementation for
> > rpmb_seq_cmd() handler. The interface enables sending sequence of RPMB
> > standard frames.
> > 
> > A parallel user space API is provided via /dev/rpmbX character device with
> > two IOCTL commands.
> > Simplified one, RPMB_IOC_REQ_CMD, were read result cycles is performed
> > by the framework on behalf the user and second, RPMB_IOC_SEQ_CMD
> > where the whole RPMB sequence, including RESULT_READ is supplied by the
> > caller.
> > The latter is intended for easier adjusting of the applications that use
> > MMC_IOC_MULTI_CMD ioctl, such as
> > https://android.googlesource.com/trusty/app/storage/
> > 
> > There is a also sample tool under tools/rpmb/ directory that exercises these
> > interfaces and a simulation device that implements the device part.
> > 
> > The code is also available from:
> > 
> > https://github.com/tomasbw/linux-mei.git rpmb
> > 
> 
> Greg, can you please check if this series has addressed all your comments. 
> Are there are any more items that preventing it from merging?

Ugh, my queue is huge right now, give me a week or so to dig out of it
and review this...

Oh wait, you have almost no reviews from anyone else!  Why is it up to
me to do all of this work?  :)

Please get acks from others, at the very least, get it reviewed by other
Intel kernel developers that we know and trust.  I'm amazed you haven't
already done that!

thanks,

greg k-h
--
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 v5 4/8] char: rpmb: provide a user space interface

[Greg Kroah-Hartman]

On Thu, Sep 01, 2016 at 08:05:26PM +, Winkler, Tomas wrote:
> 
> > 
> > On Sun, Aug 07, 2016 at 09:44:03AM +, Winkler, Tomas wrote:
> > > >
> > > > On Mon 2016-07-18 23:27:49, Tomas Winkler wrote:
> > > > > The user space API is achieved via two synchronous IOCTL.
> > > >
> > > > IOCTLs?
> > >
> > > Will fix
> > >
> > > > > Simplified one, RPMB_IOC_REQ_CMD, were read result cycles is
> > > > performed
> > > > > by the framework on behalf the user and second, RPMB_IOC_SEQ_CMD
> > > > where
> > > > > the whole RPMB sequence including RESULT_READ is supplied by the
> > caller.
> > > > > The latter is intended for  easier adjusting  of the  applications
> > > > > that use MMC_IOC_MULTI_CMD ioctl.
> > > >
> > > > Why "  "?
> > > Not sure I there is enough clue in your question.
> > > >
> > > > >
> > > > > Signed-off-by: Tomas Winkler 
> > > >
> > > > > +
> > > > > +static long rpmb_ioctl(struct file *fp, unsigned int cmd,
> > > > > +unsigned long arg) {
> > > > > + return __rpmb_ioctl(fp, cmd, (void __user *)arg); }
> > > > > +
> > > > > +#ifdef CONFIG_COMPAT
> > > > > +static long rpmb_compat_ioctl(struct file *fp, unsigned int cmd,
> > > > > +   unsigned long arg)
> > > > > +{
> > > > > + return  __rpmb_ioctl(fp, cmd, compat_ptr(arg));
> > > > > +}
> > > > > +#endif /* CONFIG_COMPAT */
> > > >
> > > > Description of the ioctl is missing,
> > > Will add.
> > >
> > > and it should certainly be designed in a way
> > > > that it does not need compat support.
> > >
> > > The compat_ioctl handler just casts the compat_ptr, I believe this
> > > should be done unless the ioctl is globaly registered in
> > > fs/compat_ioctl.c, but I might be wrong.
> > 
> > You shouldn't need a compat ioctl for anything new that is added, unless
> > your api is really messed up.  Please test to be sure, and not use a compat
> > ioctl at all, it isn't that hard to do.
> 
> compat_ioctl is called anyhow when CONFIG_COMPAT is set, there is no
> way around it, or I'm missing something?  Actually there is no more
> than that for the COMPAT support in this code.

If you don't provide a compat_ioctl() all should be fine, right?

thanks,

greg k-h
--
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 v5 5/8] char: rpmb: add RPMB simulation device

[Greg Kroah-Hartman]

On Thu, Sep 01, 2016 at 08:25:28PM +, Winkler, Tomas wrote:
> > On Mon, Jul 18, 2016 at 11:27:50PM +0300, Tomas Winkler wrote:
> > > This is a simple platform device used for testing the RPMB subsystem.
> > > +static struct platform_device *rpmb_sim_pdev;
> > 
> > A platform device?  Ick, no please don't abuse that interface for this type 
> > of
> > thing.  Make it a real device if you have one, and put it in the proper 
> > place.  If
> > it's a "virtual" device, great, use that.  But don't make something up like 
> > this
> > please.
> 
> This is a virtual device (simulation), nothing behind it just a chunk of 
> memory.
> Is this there any information missing to make it clearer? 

Don't make it a platform device, make it a "virtual" device, don't abuse
the platform device/driver interface for something that isn't really a
platform device.

thanks,

greg k-h
--
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 v5 3/8] char: rpmb: add device attributes

[Greg Kroah-Hartman]

On Mon, Jul 18, 2016 at 11:27:48PM +0300, Tomas Winkler wrote:
> Add attribute type that displays underlay storage type technology
> EMMC, UFS, and attribute id, that displays underlay storage device id.
> For EMMC this would be content of CID and for UFS serial number from
> the device descriptor.
> 
> 
> Signed-off-by: Tomas Winkler 
> ---
> V2: resend
> V3: set kernel version to 4.7
> V4: update target date to Maj
> V5: adjust date and kernel version
>  Documentation/ABI/testing/sysfs-class-rpmb | 24 
>  drivers/char/rpmb/core.c   | 63 
> ++
>  2 files changed, 87 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-rpmb 
> b/Documentation/ABI/testing/sysfs-class-rpmb
> index 3ffcd2d1f683..7ca97d86bd97 100644
> --- a/Documentation/ABI/testing/sysfs-class-rpmb
> +++ b/Documentation/ABI/testing/sysfs-class-rpmb
> @@ -18,3 +18,27 @@ Contact:   Tomas Winkler 
>  Description:
>   The /sys/class/rpmb/rpmbN directory is created for
>   each RPMB registered device
> +
> +What:/sys/class/rpmb/rpmbN/id
> +Date:Aug 2016
> +KernelVersion:   4.8
> +Contact: Tomas Winkler 
> +Description:
> + The /sys/class/rpmb/rpmbN/id file contains device id
> + in a binary form

Oops, missed that you added these in a later patch, sorry about comment
on patch 2.

binary attribute?  Why?

> +
> +What:/sys/class/rpmb/rpmbN/type
> +Date:Aug 2016
> +KernelVersion:   4.8
> +Contact: Tomas Winkler 
> +Description:
> + The /sys/class/rpmb/rpmbN/type file contains device
> + underlay storage type technology: EMMC, UFS
> +

What is this used for?

> +What:/sys/class/rpmb/rpmbN/reliable_wr_cnt
> +Date:Aug 2016
> +KernelVersion:   4.8
> +Contact: Tomas Winkler 
> +Description:
> + The /sys/class/rpmb/rpmbN/reliable_wr_cnt file contains
> + number of blocks that can be written in a single request

Why is this needed?  Shouldn't the normal block device export this type
of information?


> diff --git a/drivers/char/rpmb/core.c b/drivers/char/rpmb/core.c
> index ff10cbb7b644..63271c7ed072 100644
> --- a/drivers/char/rpmb/core.c
> +++ b/drivers/char/rpmb/core.c
> @@ -308,6 +308,67 @@ struct rpmb_dev *rpmb_dev_find_by_device(struct device 
> *parent)
>  }
>  EXPORT_SYMBOL_GPL(rpmb_dev_find_by_device);
>  
> +static ssize_t type_show(struct device *dev,
> +  struct device_attribute *attr, char *buf)
> +{
> + struct rpmb_dev *rdev = to_rpmb_dev(dev);
> + ssize_t ret;
> +
> + switch (rdev->ops->type) {
> + case RPMB_TYPE_EMMC:
> + ret = scnprintf(buf, PAGE_SIZE, "EMMC\n");

It's a sysfs file, no need for scnprintf() crap, just use sprintf()
please.

> + break;

And the code can be made smaller by just doing:
return sprintf(buf, "EMMC\n");

:)

> + case RPMB_TYPE_UFS:
> + ret = scnprintf(buf, PAGE_SIZE, "UFS\n");
> + break;
> + default:
> + ret = scnprintf(buf, PAGE_SIZE, "UNKNOWN\n");
> + break;
> + }
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(type);
> +
> +static ssize_t id_show(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + struct rpmb_dev *rdev = to_rpmb_dev(dev);
> + size_t sz = min_t(size_t, rdev->ops->dev_id_len, PAGE_SIZE);
> +
> + if (!rdev->ops->dev_id)
> + return 0;
> +
> + memcpy(buf, rdev->ops->dev_id, sz);
>

Hm, no.  That's not how a binary attribute works.  If you want a binary
attribute, use that type, don't put binary data in a "normal" sysfs
file.

> + return sz;
> +}
> +static DEVICE_ATTR_RO(id);
> +
> +static ssize_t reliable_wr_cnt_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct rpmb_dev *rdev = to_rpmb_dev(dev);
> +
> + return scnprintf(buf, PAGE_SIZE, "%u\n", rdev->ops->reliable_wr_cnt);
> +}
> +static DEVICE_ATTR_RO(reliable_wr_cnt);
> +
> +static struct attribute *rpmb_attrs[] = {
> + _attr_type.attr,
> + _attr_id.attr,
> + _attr_reliable_wr_cnt.attr,
> + NULL,
> +};
> +
> +static struct attribute_group rpmb_attr_group = {
> + .attrs = rpmb_attrs,
> +};
> +
> +static const struct attribute_group *rpmb_attr_groups[] = {
> + _attr_group,
> + NULL
> +};
> +
>  /**
>   * rpmb_dev_unregister - unregister RPMB partition from the RPMB subsystem
>   *
> @@ -377,6 +438,8 @@ struct rpmb_dev *rpmb_dev_register(struct device *dev,
>   dev_set_name(>dev, "rpmb%d", id);
>   rdev->dev.class = _class;
>   rdev->dev.parent = dev;
> + rdev->dev.groups = rpmb_attr_groups;

Nice job with the 

Re: [PATCH v5 5/8] char: rpmb: add RPMB simulation device

[Greg Kroah-Hartman]

On Mon, Jul 18, 2016 at 11:27:50PM +0300, Tomas Winkler wrote:
> This is a simple platform device used for testing
> the RPMB subsystem.
> 
> The module currently supports two configuration options:
> 1. max_wr_blks: for specifying max blocks that can be written
> in a single command
> 2. daunits:  used to set storage capacity in 128K units.
> 
> 
> Signed-off-by: Tomas Winkler 
> ---
> V2: remove .owner setting, it is set automatically
> V3: 1. Add shutdown handler (similar to ufshcd)
> 2. Commit message fix
> V4: Use select RPMB in Kconfg to ensure valid configuration.
> V5: Revamp the code using the sequence command.
> 
>  drivers/char/rpmb/Kconfig|  10 +
>  drivers/char/rpmb/Makefile   |   1 +
>  drivers/char/rpmb/rpmb_sim.c | 668 
> +++
>  3 files changed, 679 insertions(+)
>  create mode 100644 drivers/char/rpmb/rpmb_sim.c
> 
> diff --git a/drivers/char/rpmb/Kconfig b/drivers/char/rpmb/Kconfig
> index 6794be9fcc5e..c21b3934249f 100644
> --- a/drivers/char/rpmb/Kconfig
> +++ b/drivers/char/rpmb/Kconfig
> @@ -13,3 +13,13 @@ config RPMB_INTF_DEV
>   help
> Say yes here if you want to access RPMB from user space
> via character device interface /dev/rpmb%d
> +
> +
> +config RPMB_SIM
> + tristate "RPMB partition device simulator"
> + default n
> + select RPMB
> + select CRYPTO_SHA256
> + select CRYPTO_HMAC
> + help
> +   RPMB partition simulator used for testing the RPMB subsystem
> diff --git a/drivers/char/rpmb/Makefile b/drivers/char/rpmb/Makefile
> index b5dc087b1299..81f924fd9a87 100644
> --- a/drivers/char/rpmb/Makefile
> +++ b/drivers/char/rpmb/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_RPMB) += rpmb.o
>  rpmb-objs += core.o
>  rpmb-$(CONFIG_RPMB_INTF_DEV) += cdev.o
> +obj-$(CONFIG_RPMB_SIM) += rpmb_sim.o
>  
>  ccflags-y += -D__CHECK_ENDIAN__
> diff --git a/drivers/char/rpmb/rpmb_sim.c b/drivers/char/rpmb/rpmb_sim.c
> new file mode 100644
> index ..e33f6809ae2c
> --- /dev/null
> +++ b/drivers/char/rpmb/rpmb_sim.c
> @@ -0,0 +1,668 @@
> +/**
> + * This file is provided under a dual BSD/GPLv2 license.  When using or
> + * redistributing this file, you may do so under either license.
> + *
> + * GPL LICENSE SUMMARY
> + *
> + * Copyright(c) 2016 Intel Corporation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * The full GNU General Public License is included in this distribution
> + * in the file called LICENSE.GPL.
> + *
> + * Contact Information:
> + *   Intel Corporation.
> + *   linux-...@linux.intel.com
> + *   http://www.intel.com
> + *
> + * BSD LICENSE
> + *
> + * Copyright(c) 2016 Intel Corporation. All rights reserved.
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + *  * Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + *  * Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in
> + *the documentation and/or other materials provided with the
> + *distribution.
> + *  * Neither the name Intel Corporation nor the names of its
> + *contributors may be used to endorse or promote products derived
> + *from this software without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + *
> + 
> */
> +#include 
> +#include 
> +#include 
> 

Re: [PATCH v5 5/8] char: rpmb: add RPMB simulation device

[Greg Kroah-Hartman]

On Mon, Jul 18, 2016 at 11:27:50PM +0300, Tomas Winkler wrote:
> This is a simple platform device used for testing
> the RPMB subsystem.
> 
> The module currently supports two configuration options:
> 1. max_wr_blks: for specifying max blocks that can be written
> in a single command
> 2. daunits:  used to set storage capacity in 128K units.
> 
> 
> Signed-off-by: Tomas Winkler 
> ---
> V2: remove .owner setting, it is set automatically
> V3: 1. Add shutdown handler (similar to ufshcd)
> 2. Commit message fix
> V4: Use select RPMB in Kconfg to ensure valid configuration.
> V5: Revamp the code using the sequence command.
> 
>  drivers/char/rpmb/Kconfig|  10 +
>  drivers/char/rpmb/Makefile   |   1 +
>  drivers/char/rpmb/rpmb_sim.c | 668 
> +++
>  3 files changed, 679 insertions(+)
>  create mode 100644 drivers/char/rpmb/rpmb_sim.c
> 
> diff --git a/drivers/char/rpmb/Kconfig b/drivers/char/rpmb/Kconfig
> index 6794be9fcc5e..c21b3934249f 100644
> --- a/drivers/char/rpmb/Kconfig
> +++ b/drivers/char/rpmb/Kconfig
> @@ -13,3 +13,13 @@ config RPMB_INTF_DEV
>   help
> Say yes here if you want to access RPMB from user space
> via character device interface /dev/rpmb%d
> +
> +
> +config RPMB_SIM
> + tristate "RPMB partition device simulator"
> + default n
> + select RPMB
> + select CRYPTO_SHA256
> + select CRYPTO_HMAC
> + help
> +   RPMB partition simulator used for testing the RPMB subsystem

Hm, that's very vague, why would I want this?  Not want this?  Please
provide more information here.

thanks,

greg k-h
--
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 v5 2/8] char: rpmb: add sysfs-class ABI documentation

[Greg Kroah-Hartman]

On Mon, Jul 18, 2016 at 11:27:47PM +0300, Tomas Winkler wrote:
> Signed-off-by: Tomas Winkler 
> ---
> V2: resend
> V3: add more verbose description
> V4: resend
> V5: adjust date and kernel version
> 
>  Documentation/ABI/testing/sysfs-class-rpmb | 20 
>  MAINTAINERS|  1 +
>  2 files changed, 21 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-rpmb
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-rpmb 
> b/Documentation/ABI/testing/sysfs-class-rpmb
> new file mode 100644
> index ..3ffcd2d1f683
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-rpmb
> @@ -0,0 +1,20 @@
> +What:/sys/class/rpmb/
> +Date:Aug 2016
> +KernelVersion:  4.8
> +Contact: Tomas Winkler 
> +Description:
> + The rpmb/ class sub-directory belongs to RPMB device class.
> +
> + Few storage technologies such is EMMC, UFS, and NVMe support
> + Replay Protected Memory Block (RPMB) hardware partition with
> + common protocol and frame layout.
> + Such a partition provides authenticated and replay protected 
> access,
> + hence suitable as a secure storage.
> +
> +What:/sys/class/rpmb/rpmbN/
> +Date:Aug 2016
> +KernelVersion:   4.8
> +Contact: Tomas Winkler 
> +Description:
> + The /sys/class/rpmb/rpmbN directory is created for
> + each RPMB registered device

So you have no sysfs files?  If not, why have a sysfs class at all?

thanks,

greg k-h
--
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 v5 4/8] char: rpmb: provide a user space interface

[Greg Kroah-Hartman]

On Sun, Aug 07, 2016 at 09:44:03AM +, Winkler, Tomas wrote:
> > 
> > On Mon 2016-07-18 23:27:49, Tomas Winkler wrote:
> > > The user space API is achieved via two synchronous IOCTL.
> > 
> > IOCTLs?
> 
> Will fix
>  
> > > Simplified one, RPMB_IOC_REQ_CMD, were read result cycles is
> > performed
> > > by the framework on behalf the user and second, RPMB_IOC_SEQ_CMD
> > where
> > > the whole RPMB sequence including RESULT_READ is supplied by the caller.
> > > The latter is intended for  easier adjusting  of the  applications
> > > that use MMC_IOC_MULTI_CMD ioctl.
> > 
> > Why "  "?
> Not sure I there is enough clue in your question. 
> > 
> > >
> > > Signed-off-by: Tomas Winkler 
> > 
> > > +
> > > +static long rpmb_ioctl(struct file *fp, unsigned int cmd, unsigned
> > > +long arg) {
> > > + return __rpmb_ioctl(fp, cmd, (void __user *)arg); }
> > > +
> > > +#ifdef CONFIG_COMPAT
> > > +static long rpmb_compat_ioctl(struct file *fp, unsigned int cmd,
> > > +   unsigned long arg)
> > > +{
> > > + return  __rpmb_ioctl(fp, cmd, compat_ptr(arg));
> > > +}
> > > +#endif /* CONFIG_COMPAT */
> > 
> > Description of the ioctl is missing, 
> Will add. 
> 
> and it should certainly be designed in a way
> > that it does not need compat support.
> 
> The compat_ioctl handler just casts the compat_ptr, I believe this
> should be done unless the ioctl is globaly registered in
> fs/compat_ioctl.c, but I might be wrong.

You shouldn't need a compat ioctl for anything new that is added, unless
your api is really messed up.  Please test to be sure, and not use a
compat ioctl at all, it isn't that hard to do.

thanks,

greg k-h
--
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] sd: Optimal I/O size is in bytes, not sectors

[Greg Kroah-Hartman]

On Wed, Jan 20, 2016 at 08:47:29AM -0800, James Bottomley wrote:
> On Wed, 2016-01-20 at 11:40 -0500, Martin K. Petersen wrote:
> > > > > > > "James" == James Bottomley <
> > > > > > > james.bottom...@hansenpartnership.com> writes:
> > 
> > James> We should mark the commit causing the problems, which went
> > into
> > James> 4.4 if I remember correctly:
> > 
> > James> Fixes: ca369d51b3e1649be4a72addd6d6a168cfb3f537 Cc:
> > James> sta...@vger.kernel.org # 4.4+ Reviewed-by: James E.J.
> > Bottomley
> > James> 
> > 
> > I'll add the tags. The reason I didn't explicitly put 4.4+ is that 
> > the original commit has made its way quite far in various stable 
> > trees by now.
> 
> It has?  It wasn't tagged for stable.  However, if it got applied to
> stable trees, then we should certainly backport further.  I sort of
> hope the stable process uses the Fixes: tag to decide when to backport
> anyway, since the stable commit contains the original upstream sha256,
> they can certainly identify it.
> 
> Greg, are we OK not to bother with qualifying the cc: stable tag if we
> have a Fixes tag, or do you still want to see both?  Perhaps an
> addition to stable_kernel_rules.txt mentioning Fixes: might be useful
> as well.

I want to see a stable tag if you know it is relevant.  I do, when I
have the time, dig through the fixes: tags to see if they should also be
applied, but I don't always guarantee that I will get to them at all, so
don't count on that as a way to get a patch into a stable release.

thanks,

greg k-h
--
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.1] target-core: fix return without a value

[Greg Kroah-Hartman]

On Tue, Nov 10, 2015 at 01:32:10PM -0500, Mikulas Patocka wrote:
> Fix the warning drivers/target/target_core_pr.c:332:3: warning: 'return'
> with no value, in function returning non-void [-Wreturn-type]
> 
> The patch 35afa65642a9a88c81913377b93a3a66220f8b9d committed to 4.1.11
> adds a check if device_list is NULL. The patch adds a return statement
> without a value to the function core_scsi3_pr_seq_non_holder that returns
> int.
> 
> Signed-off-by: Mikulas Patocka 
> 
> ---
>  drivers/target/target_core_pr.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.


--
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.1] target-core: fix return without a value

[Greg Kroah-Hartman]

On Tue, Nov 10, 2015 at 06:31:47PM -0500, Mikulas Patocka wrote:
> 
> 
> On Tue, 10 Nov 2015, Greg Kroah-Hartman wrote:
> 
> > On Tue, Nov 10, 2015 at 01:32:10PM -0500, Mikulas Patocka wrote:
> > > Fix the warning drivers/target/target_core_pr.c:332:3: warning: 'return'
> > > with no value, in function returning non-void [-Wreturn-type]
> > > 
> > > The patch 35afa65642a9a88c81913377b93a3a66220f8b9d committed to 4.1.11
> > > adds a check if device_list is NULL. The patch adds a return statement
> > > without a value to the function core_scsi3_pr_seq_non_holder that returns
> > > int.
> > > 
> > > Signed-off-by: Mikulas Patocka <mpato...@redhat.com>
> > > 
> > > ---
> > >  drivers/target/target_core_pr.c |2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > 
> > 
> > This is not the correct way to submit patches for inclusion in the
> > stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
> > for how to do this properly.
> > 
> > 
> 
> This patch has no upstream equivalent (because the code in upstream was 
> already refactored), so none of the rules in stable_kernel_rules.txt apply 
> to it. The patch that broke it also has no upstream equivalent.
>

Then you need to say that!

And the fact that a "please take this patch, it's correct but doesn't
apply to upstream" patch is now broken is proof of why I didn't want to
take it in the first place!

Ugh.  How about I just revert the original patch and then you send me
backports of what is actually in Linus's tree so we don't have this
problem anymore?

Oh, and you got the stable mailing list address wrong as well :(

Please fix all of this up and resend.

thanks,

greg k-h
--
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] scsi: dpt: remove i2o header in uapi

[Greg Kroah-Hartman]

On Sun, Oct 04, 2015 at 01:22:50AM +0200, Gabriel Laskar wrote:
> The i2o subsystem was removed by
> commit 4a72a7af462d ("staging: remove i2o subsystem") but the header was
> still used by drivers/scsi/dpt_i2o.c driver.
> 
> This patch moves the structures used from the header into dpti_i2o.h.
> 
> CC: Arnd Bergmann <a...@arndb.de>
> CC: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Signed-off-by: Gabriel Laskar <gabr...@lse.epita.fr>
> ---
>  drivers/scsi/dpt/dpti_i2o.h  | 134 +-
>  include/uapi/linux/Kbuild|   1 -
>  include/uapi/linux/i2o-dev.h | 421 
> ---
>  3 files changed, 132 insertions(+), 424 deletions(-)
>  delete mode 100644 include/uapi/linux/i2o-dev.h

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
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 V5 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[Greg Kroah-Hartman]

On Sun, Sep 27, 2015 at 03:48:24PM +0200, Rafael J. Wysocki wrote:
> On Sun, Sep 27, 2015 at 12:04 AM, Viresh Kumar  
> wrote:
> > global_lock is defined as an unsigned long and accessing only its lower
> > 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> > for big endian 64-bit systems. There are no such platforms yet, but the
> > code needs to be robust for such a case.
> >
> > Fix that by changing type of 'global_lock' to u32.
> >
> > Signed-off-by: Viresh Kumar 
> 
> Acked-by: Rafael J. Wysocki 
> 
> Greg, please take this one along with the [2/2] if that one looks good to you.

Thanks, will do.

greg k-h
--
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] uas: disable UAS on Apricorn SATA dongles

[Greg Kroah-Hartman]

On Fri, Dec 12, 2014 at 11:42:12AM +0100, Hans de Goede wrote:
 Adding Greg and stable to the cc
 
 On 11-12-14 20:01, Darrick J. Wong wrote:
 The Apricorn SATA dongle will occasionally return USBSUSBSUSB in
 response to SCSI commands when running in UAS mode.  Therefore,
 disable UAS mode on this dongle.
 
 Signed-off-by: Darrick J. Wong darrick.w...@oracle.com
 
 Looks good:
 
 Acked-by: Hans de Goede hdego...@redhat.com
 
 Greg, can you add this to your tree please ?

Sure, will queue up after 3.19-rc1 is out.

thanks,

greg k-h
--
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: [V2 PATCH 3/4] scsi:stex.c Add reboot support

[Greg Kroah-Hartman]

On Wed, Nov 12, 2014 at 09:27:50AM -0800, Christoph Hellwig wrote:
  +static int stex_reboot_callback(struct notifier_block *self,
  + unsigned long val,
  + void *data)
  +{
  +   if (val == SYS_RESTART)
  +   isRestart = 1;
  +   return NOTIFY_OK;
  +}
  
  @@ -1832,7 +1859,14 @@ static void stex_shutdown(struct pci_dev *pdev)
   {
  struct st_hba *hba = pci_get_drvdata(pdev);
  
  -   stex_hba_stop(hba);
  +   if (hba-yellowstone == 1)
  +   stex_hba_stop(hba, ST_IGNORED);
  +   else {
  +   if (isRestart)
  +   stex_hba_stop(hba, ST_S6);
  +   else
  +   stex_hba_stop(hba, ST_S5);
  +   }
 
 This sort of check for reboot vs restart isn't really something
 we want in drivers.  I don't really know how we could find this
 out assuming we even want drivers to behave differently.
 
 Maybe Greg or someone on lkml has an idea how to best handle this case.

What is this case?

And yes, I agree, we shouldn't care, in drivers, about reboot vs.
restart, as they should both be the same thing, along with disconnect,
right?

thanks,

greg k-h
--
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 3.10 098/123] scsi: Fix error handling in SCSI_IOCTL_SEND_COMMAND

[Greg Kroah-Hartman]

3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara j...@suse.cz

commit 84ce0f0e94ac97217398b3b69c21c7a62ebeed05 upstream.

When sg_scsi_ioctl() fails to prepare request to submit in
blk_rq_map_kern() we jump to a label where we just end up copying
(luckily zeroed-out) kernel buffer to userspace instead of reporting
error. Fix the problem by jumping to the right label.

CC: Jens Axboe ax...@kernel.dk
CC: linux-scsi@vger.kernel.org
Coverity-id: 1226871
Signed-off-by: Jan Kara j...@suse.cz
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

Fixed up the, now unused, out label.

Signed-off-by: Jens Axboe ax...@fb.com

---
 block/scsi_ioctl.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -506,7 +506,7 @@ int sg_scsi_ioctl(struct request_queue *
 
if (bytes  blk_rq_map_kern(q, rq, buffer, bytes, __GFP_WAIT)) {
err = DRIVER_ERROR  24;
-   goto out;
+   goto error;
}
 
memset(sense, 0, sizeof(sense));
@@ -516,7 +516,6 @@ int sg_scsi_ioctl(struct request_queue *
 
blk_execute_rq(q, disk, rq, 0);
 
-out:
err = rq-errors  0xff;/* only 8 bit SCSI status */
if (err) {
if (rq-sense_len  rq-sense) {


--
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 3.14 168/203] scsi: Fix error handling in SCSI_IOCTL_SEND_COMMAND

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara j...@suse.cz

commit 84ce0f0e94ac97217398b3b69c21c7a62ebeed05 upstream.

When sg_scsi_ioctl() fails to prepare request to submit in
blk_rq_map_kern() we jump to a label where we just end up copying
(luckily zeroed-out) kernel buffer to userspace instead of reporting
error. Fix the problem by jumping to the right label.

CC: Jens Axboe ax...@kernel.dk
CC: linux-scsi@vger.kernel.org
Coverity-id: 1226871
Signed-off-by: Jan Kara j...@suse.cz
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

Fixed up the, now unused, out label.

Signed-off-by: Jens Axboe ax...@fb.com

---
 block/scsi_ioctl.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -489,7 +489,7 @@ int sg_scsi_ioctl(struct request_queue *
 
if (bytes  blk_rq_map_kern(q, rq, buffer, bytes, __GFP_WAIT)) {
err = DRIVER_ERROR  24;
-   goto out;
+   goto error;
}
 
memset(sense, 0, sizeof(sense));
@@ -499,7 +499,6 @@ int sg_scsi_ioctl(struct request_queue *
 
blk_execute_rq(q, disk, rq, 0);
 
-out:
err = rq-errors  0xff;/* only 8 bit SCSI status */
if (err) {
if (rq-sense_len  rq-sense) {


--
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 3.17 249/319] scsi: Fix error handling in SCSI_IOCTL_SEND_COMMAND

[Greg Kroah-Hartman]

3.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara j...@suse.cz

commit 84ce0f0e94ac97217398b3b69c21c7a62ebeed05 upstream.

When sg_scsi_ioctl() fails to prepare request to submit in
blk_rq_map_kern() we jump to a label where we just end up copying
(luckily zeroed-out) kernel buffer to userspace instead of reporting
error. Fix the problem by jumping to the right label.

CC: Jens Axboe ax...@kernel.dk
CC: linux-scsi@vger.kernel.org
Coverity-id: 1226871
Signed-off-by: Jan Kara j...@suse.cz
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

Fixed up the, now unused, out label.

Signed-off-by: Jens Axboe ax...@fb.com

---
 block/scsi_ioctl.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -509,7 +509,7 @@ int sg_scsi_ioctl(struct request_queue *
 
if (bytes  blk_rq_map_kern(q, rq, buffer, bytes, __GFP_WAIT)) {
err = DRIVER_ERROR  24;
-   goto out;
+   goto error;
}
 
memset(sense, 0, sizeof(sense));
@@ -518,7 +518,6 @@ int sg_scsi_ioctl(struct request_queue *
 
blk_execute_rq(q, disk, rq, 0);
 
-out:
err = rq-errors  0xff;/* only 8 bit SCSI status */
if (err) {
if (rq-sense_len  rq-sense) {


--
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 2/2] uas: Make uas work with blk-mq

[Greg Kroah-Hartman]

On Sun, Oct 05, 2014 at 11:18:49AM +0200, Hans de Goede wrote:
 Hi,
 
 On 10/05/2014 11:10 AM, Christoph Hellwig wrote:
  On Sun, Oct 05, 2014 at 11:06:00AM +0200, Hans de Goede wrote:
  This patch sits on top of a lot of other uas fixes which are already
  in usb-next, so this needs to go in through usb-next.
  
  What is the actual conflict? If it's just your revert of the
  disable_blk_mq flag
 
 Yes, the conclict is just my revert of the disable_blk_mq flag
 
  you might want to skip that for this pull request
  and send it on after both scsi and usb trees make it to Linus.
 
 Since the patch with the conclict actually makes the flag unnecessary,
 to me this belongs in the same patch.
 
  If there's more conflict around the host template you could cherry pick
  my patch for your tree.
 
 Yes, Greg cherry picking the patch in question into his tree to resolv
 the conflict would be my preferred solution to this, but ultimately
 that is Greg's call.

I'm not going to do that, just resend it to me after 3.18-rc1 is out, my
tree is closed for the -rc1 merge window now anyway.

thanks,

greg k-h
--
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 2/2] uas: Make uas work with blk-mq

[Greg Kroah-Hartman]

On Fri, Oct 03, 2014 at 12:08:57PM +0200, Hans de Goede wrote:
 With uas over usb-3 the tags inside the uas iu-s must match the usb-3 stream
 ids, and those go from 1 - qdepth.
 
 Before blk-mq calling scsi_activate_tcq(sdev, qdepth) guaranteed that we would
 only get cmnd-request-tag from 0 - (qdepth - 1), and we used those as
 uas-tags / stream-ids.
 
 With blk-mq however we are guaranteed to never get more then qdepth commands
 queued at the same time, but the cmnd-request-tag values may be much larger,
 which breaks uas.
 
 This commit fixes this by generating uas tags in the 1 - qdepth range 
 ourselves
 instead of using cmnd-request-tag.
 
 While touching all involved code anyways also rename the uas_cmd_info stream
 field to uas_tag, because when using uas over usb-2 streams are not used.
 
 Cc: Christoph Hellwig h...@infradead.org
 Reported-by: Douglas Gilbert dgilb...@interlog.com
 Signed-off-by: Hans de Goede hdego...@redhat.com
 Reviewed-by: Christoph Hellwig h...@lst.de

This doesn't apply to my usb-next branch of usb.git, care to refresh it
and resend?

thanks,

greg k-h
--
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] uas: Make uas work with blk-mq

[Greg Kroah-Hartman]

On Thu, Oct 02, 2014 at 06:12:59AM -0700, Christoph Hellwig wrote:
 On Thu, Oct 02, 2014 at 03:08:40PM +0200, Hans de Goede wrote:
  Yes, although that likely would need to go through stable, without
  going into 3.18 .
  
  Greg, is this ok with you and how do I get a patch in stable which
  is not in upstream (because upstream will get a better fix) ?
 
 This is a trivial one liner and 3.17 isn't released yet, so can you just
 send it to Linus now?

Let's just wait for these patches to get into 3.18-rc1, and then, Hans,
you can send me a patch just for 3.17-stable with a note saying why it
is different from what is in Linus's tree.

Or send me that patch now and I can queue it up at the proper time.

thanks,

greg k-h
--
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 29/38] Introduce dev_printk_string() and dev_printk_header()

[Greg Kroah-Hartman]

On Mon, Sep 29, 2014 at 01:58:58PM +0200, Hannes Reinecke wrote:
 Introducing dev_printk_string() and dev_printk_header() to allow
 using an external buffer for printing via dev_printk().
 
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 Cc: Steven Rostedt rost...@goodmis.org
 Cc: LKML linux-ker...@vger.kernel.org
 Signed-off-by: Hannes Reinecke h...@suse.de
 ---
  drivers/base/core.c| 24 
  include/linux/device.h | 12 
  2 files changed, 36 insertions(+)

I don't understand, what are you trying to do with this?  I don't see
any follow-on patches that use this, nor can I find a 00/38 patch for
this series...

thanks,

greg k-h
--
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 fix for 3.17 v5] uas: Add a quirk for rejecting ATA_12 and ATA_16 commands

[Greg Kroah-Hartman]

On Mon, Sep 15, 2014 at 04:13:52PM +0200, Hans de Goede wrote:
 Hi,
 
 On 09/15/2014 04:08 PM, Greg Kroah-Hartman wrote:
  On Mon, Sep 15, 2014 at 04:04:12PM +0200, Hans de Goede wrote:
  And set this quirk for the Seagate Expansion Desk (0bc2:2312), as that one
  seems to hang upon receiving an ATA_12 or ATA_16 command.
 
  https://bugzilla.kernel.org/show_bug.cgi?id=79511
  https://bbs.archlinux.org/viewtopic.php?id=183190
 
  While at it also add missing documentation for the u value for usb-storage
  quirks.
 
  Cc: sta...@vger.kernel.org # 3.16
  Signed-off-by: Hans de Goede hdego...@redhat.com
 
  --
  Changes in v2: Add documentation for new t and u usb-storage.quirks flags
  Changes in v3: Fix typo in documentation
  Changes in v4: Also apply the quirk to (0bc2:3312)
  Changes in v5: Rebased on 3.17-rc5, drop u documentation, already upstream
  
  So I should wait another day for v6?  :)
 
 Hehe, no I certainly hope not.
 
 Chances are I there will eventually be more seagate models needing the quirk,
 but I've none in the pipeline atm, and we can always add those with an
 incremental patch.
 
 So if this is not too late for 3.17 and you can pick up v5 that would be 
 great.

It's too late for 3.17, but I'll mark it for stable for 3.17 and 3.16.

thanks,

greg k-h
--
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 fix for 3.17 v5] uas: Add a quirk for rejecting ATA_12 and ATA_16 commands

[Greg Kroah-Hartman]

On Mon, Sep 15, 2014 at 04:04:12PM +0200, Hans de Goede wrote:
 And set this quirk for the Seagate Expansion Desk (0bc2:2312), as that one
 seems to hang upon receiving an ATA_12 or ATA_16 command.
 
 https://bugzilla.kernel.org/show_bug.cgi?id=79511
 https://bbs.archlinux.org/viewtopic.php?id=183190
 
 While at it also add missing documentation for the u value for usb-storage
 quirks.
 
 Cc: sta...@vger.kernel.org # 3.16
 Signed-off-by: Hans de Goede hdego...@redhat.com
 
 --
 Changes in v2: Add documentation for new t and u usb-storage.quirks flags
 Changes in v3: Fix typo in documentation
 Changes in v4: Also apply the quirk to (0bc2:3312)
 Changes in v5: Rebased on 3.17-rc5, drop u documentation, already upstream

So I should wait another day for v6?  :)

greg k-h
--
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] uas: Add missing le16_to_cpu calls to asm1051 / asm1053 usb-id check

[Greg Kroah-Hartman]

On Thu, Sep 11, 2014 at 11:06:12AM +0200, Hans de Goede wrote:
 Cc: sta...@vger.kernel.org # 3.16
 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  drivers/usb/storage/uas-detect.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

You forgot the reported-by line, I'll go add it...
--
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] Do not use platform_bus as a parent

[Greg Kroah-Hartman]

On Sun, Jul 27, 2014 at 07:52:57AM +0400, James Bottomley wrote:
 On Sat, 2014-07-26 at 13:11 -0700, Greg Kroah-Hartman wrote:
  On Fri, Jul 25, 2014 at 07:46:56AM -0700, James Bottomley wrote:
   On Fri, 2014-07-25 at 15:23 +0100, Pawel Moll wrote:
The host devices without a parent were forcefully adopted
by platform bus. This patch removes this assignment. In
effect the dev_dev may be NULL now, which means ISA.

Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Pawel Moll pawel.m...@arm.com
---

This patch is a part of effort to remove references to platform_bus
and make it static.

James, could you please have a look and advice if the change is
correct? Would you happen to know the real reasons behind
using the root platform_bus device a parent?
   
   Yes, for DMA purposes, the parent cannot now be NULL; we'll get a panic
   in the DMA transfers if it is.  A lot of the legacy ISA device on x86
   and I thought some ARM SOC devices don't pass in the parent device, so
   we hang them off a known parent.
  
  The generic platform bus device is not a known parent.  I don't
  understand the difference between just setting the parent to be NULL,
  which will then have a proper parent pointer filled in by the driver
  core when the device is registered, or faking it out here.  What is the
  difference?
 
 If you set the parent to NULL, the host template dma_dev will end up
 NULL as well and that will trigger a NULL deref panic in the dma segment
 routines.

 If you want to remove platform_bus, we have to have a well known device
 to set dma_dev to at scsi_host_add time.

Why not set the dma_dev after you call device_add()?  That way you will
pick up the right parent no matter what.

  In the end, the device always ends up with a parent pointer, right?
 
 The parent pointer isn't the problem ... assigning the correct dma
 device is.

Ah, ok, it's a scsi core thing, not a driver core thing, that's less
confusing now.  For a fallback of a platform device, if you switch the
lines around you should be fine, something like this patch perhaps:

diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index 3cbb57a8b846..d8d3b294f5bc 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -218,16 +218,16 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, 
struct device *dev,
goto fail;
 
if (!shost-shost_gendev.parent)
-   shost-shost_gendev.parent = dev ? dev : platform_bus;
-   if (!dma_dev)
-   dma_dev = shost-shost_gendev.parent;
-
-   shost-dma_dev = dma_dev;
+   shost-shost_gendev.parent = dev;
 
error = device_add(shost-shost_gendev);
if (error)
goto out;
 
+   if (!dma_dev)
+   dma_dev = shost-shost_gendev.parent;
+   shost-dma_dev = dma_dev;
+
pm_runtime_set_active(shost-shost_gendev);
pm_runtime_enable(shost-shost_gendev);
device_enable_async_suspend(shost-shost_gendev);
--
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.15 099/139] libiscsi, iser: Adjust data_length to include protection information

[Greg Kroah-Hartman]

On Thu, Jul 03, 2014 at 06:54:05AM -0700, James Bottomley wrote:
 On Wed, 2014-07-02 at 23:05 -0700, Christoph Hellwig wrote:
  On Wed, Jul 02, 2014 at 03:52:35PM -0700, James Bottomley wrote:
   In which case it's not marked for stable backport ... I assume it should
   be?
  
  Only if the patch that regression went to stable, which it shouldn't,
 
 Well it did:
 
 https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/scsi?h=linux-3.15.yid=04423ddea30a7fb7232636eda8aed55ea5b972fe
 
 The stable process is a bit broken from my point of view since it
 doesn't copy linux-scsi on SCSI commits

I copy everyone on the patch.  You were not on that patch as it doesn't
look like it went through your tree at all.

 ... but this time even I didn't get a cc, so really no-one who knew
 there was a problem had a chance to comment.

The target people (Nicholas) asked for the patch to be applied, they
knew what was going on here.

 The choice is either request revert from stable or add fix.

Agreed, just let me know.

greg k-h
--
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: [RESEND][PATCH] scsi: esas2r: fix potential format string flaw

[Greg Kroah-Hartman]

On Tue, Dec 17, 2013 at 10:27:33AM -0800, Kees Cook wrote:
 This makes sure format strings cannot leak into the printk call via the
 constructed buffer.
 
 Signed-off-by: Kees Cook keesc...@chromium.org
 ---
  drivers/scsi/esas2r/esas2r_log.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Why is this patch To: me?  I'm not the author of this driver, or the
maintainer of it or the subsystem, and there's not much, if anything I
can do with it...

confused,

greg k-h
--
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 25/36] SCSI: sd: convert class code to use dev_groups

[Greg Kroah-Hartman]

On Tue, Jul 30, 2013 at 04:11:52PM +, James Bottomley wrote:
 On Wed, 2013-07-24 at 15:05 -0700, Greg Kroah-Hartman wrote:
  The dev_attrs field of struct class is going away soon, dev_groups
  should be used instead.  This converts the scsi disk class code to use
  the correct field.
  
  It required some functions to be moved around to place the show and
  store functions next to each other, the old order seemed to make no
  sense at all.
  
  Cc: James E.J. Bottomley jbottom...@parallels.com
  Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
  ---
  
  James, feel free to take this through your tree, or ACK it and I can
  take it through mine.
 
 Just found this ... I have the stable folder rule be git-send-email and
 from you, so it picks up your patches as well.

It seems you aren't the only one who has procmail rules for my emails :)

I wonder if I need to start sending my stable stuff out from a different
email address...

 I'll take it through my tree, just in case we're mucking about with
 attributes this cycle around.

That's fine with me, thanks.

greg k-h
--
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 2/2] Adds new device resume mode in PM core, async plus non-blocking

[Greg Kroah-Hartman]

On Fri, May 17, 2013 at 07:05:33PM +, Brandt, Todd E wrote:
 Updates the drivers/base/power subsystem to allow any devices which
 have registred as asynchronous and who have not registered complete
 callbacks to be non-blocking. i.e system resume can finish and return
 control to the user while these devices continue resuming.
 
 Changelog:
 v2:
 - Updated patch submission. Incorporates comments from Tejun Heo.   
   Fixed comment format, removed camelcase. No functional changes.
 
 Signed-off-by: Todd Brandt todd.e.bra...@intel.com
 ---
  drivers/base/power/main.c |   20 
  1 file changed, 16 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
 index 2b7f77d..1b16379 100644
 --- a/drivers/base/power/main.c
 +++ b/drivers/base/power/main.c
 @@ -713,7 +713,6 @@ void dpm_resume(pm_message_t state)
   put_device(dev);
   }
   mutex_unlock(dpm_list_mtx);
 - async_synchronize_full();
   dpm_show_time(starttime, state, NULL);
  }
  
 @@ -726,11 +725,14 @@ static void device_complete(struct device *dev, 
 pm_message_t state)
  {
   void (*callback)(struct device *) = NULL;
   char *info = NULL;
 + bool hascb = false;

hascb?  Please spell out what this is.

  
   if (dev-power.syscore)
   return;
  
 - device_lock(dev);
 + docomplete:
 + if (hascb)
 + device_lock(dev);
  
   if (dev-pm_domain) {
   info = completing power domain ;
 @@ -751,13 +753,21 @@ static void device_complete(struct device *dev, 
 pm_message_t state)
   callback = dev-driver-pm-complete;
   }
  
 + /*
 +  * if a callback exists, lock the device and call it
 +  * otherwise don't even lock/unlock the device
 +  */
   if (callback) {
 + if (!hascb) {
 + hascb = true;
 + goto docomplete;

You want to jump backwards?  This isn't the scheduler, please, you can
do better here.

thanks,

greg k-h
--
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 02/02] scsi: pcmcia: nsp_cs: remove module init/exit function prototypes

[Greg Kroah-Hartman]

From: H Hartley Sweeten hswee...@visionengravers.com

This driver now uses the module_pcmcia_driver() macro to supply the
init/exit code. The nsp_cs_{init,exit} prototypes should be removed.

Reported-by: kbuild test robot fengguang...@intel.com
Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com
Cc: YOKOTA Hiroshi yok...@netlab.is.tsukuba.ac.jp
Cc: James E.J. Bottomley jbottom...@parallels.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
 drivers/scsi/pcmcia/nsp_cs.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/scsi/pcmcia/nsp_cs.h b/drivers/scsi/pcmcia/nsp_cs.h
index 7fc9a9d..4d4b4f5 100644
--- a/drivers/scsi/pcmcia/nsp_cs.h
+++ b/drivers/scsi/pcmcia/nsp_cs.h
@@ -331,10 +331,6 @@ static struct Scsi_Host *nsp_detect(struct 
scsi_host_template *sht);
 /* Interrupt handler */
 //static irqreturn_t nspintr(int irq, void *dev_id);
 
-/* Module entry point*/
-static int  __init nsp_cs_init(void);
-static void __exit nsp_cs_exit(void);
-
 /* Debug */
 #ifdef NSP_DEBUG
 static void show_command (struct scsi_cmnd *SCpnt);
-- 
1.8.2.1.368.g99c2266

--
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

[ 11/11] scsi: Silence unnecessary warnings about ioctl to partition

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara j...@suse.cz

commit 6d9359280753d2955f86d6411047516a9431eb51 upstream.

Sometimes, warnings about ioctls to partition happen often enough that they
form majority of the warnings in the kernel log and users complain. In some
cases warnings are about ioctls such as SG_IO so it's not good to get rid of
the warnings completely as they can ease debugging of userspace problems
when ioctl is refused.

Since I have seen warnings from lots of commands, including some proprietary
userspace applications, I don't think disallowing the ioctls for processes
with CAP_SYS_RAWIO will happen in the near future if ever. So lets just
stop warning for processes with CAP_SYS_RAWIO for which ioctl is allowed.

Acked-by: Paolo Bonzini pbonz...@redhat.com
CC: James Bottomley jbottom...@parallels.com
CC: linux-scsi@vger.kernel.org
Signed-off-by: Jan Kara j...@suse.cz
Signed-off-by: Jens Axboe ax...@kernel.dk
Cc: Satoru Takeuchi satoru.takeu...@gmail.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

---
 block/scsi_ioctl.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -722,11 +722,14 @@ int scsi_verify_blk_ioctl(struct block_d
break;
}
 
+   if (capable(CAP_SYS_RAWIO))
+   return 0;
+
/* In particular, rule out all resets and host-specific ioctls.  */
printk_ratelimited(KERN_WARNING
   %s: sending ioctl %x to a partition!\n, 
current-comm, cmd);
 
-   return capable(CAP_SYS_RAWIO) ? 0 : -ENOTTY;
+   return -ENOTTY;
 }
 EXPORT_SYMBOL(scsi_verify_blk_ioctl);
 


--
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: linux-next: build failure after merge of the pci tree

[Greg Kroah-Hartman]

On Tue, Nov 06, 2012 at 11:27:29AM +1100, Stephen Rothwell wrote:
 Hi Bjorn,
 
 After merging the pci tree, today's linux-next build (x86_64 allmodconfig)
 failed like this:
 
 drivers/staging/telephony/ixj.c: In function 'ixj_probe_pci':
 drivers/staging/telephony/ixj.c:7732:13: warning: assignment makes integer 
 from pointer without a cast [enabled by default]
 drivers/staging/telephony/ixj.c:7732:38: error: expected ';' before 
 'pci_resource_start'
 
 Exposed by commit 545974a28f78 (PCI: Convert pci_resource_foo macros to
 static inlines).  The macro version of pci_resource_start() made this
 RHS look like a function call and now it isn't.
 
 Maybe it is time this driver just went away.

It is gone in my tree, and it should be deleted in yours, do you not see
that?

thanks,

greg k-h
--
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] tcm_vhost: Expose ABI version via VHOST_SCSI_GET_ABI_VERSION

[Greg Kroah-Hartman]

On Tue, Jul 24, 2012 at 01:26:20AM +, Nicholas A. Bellinger wrote:
 From: Nicholas Bellinger n...@linux-iscsi.org
 
 As requested by Anthony, here is a patch against target-pending/for-next-merge
 to expose an ABI version to userspace via a new VHOST_SCSI_GET_ABI_VERSION
 ioctl operation.
 
 As mentioned in the comment, ABI Rev 0 is for pre 2012 out-of-tree code, and
 ABI Rev 1 (the current rev) is for current WIP v3.6 kernel merge candiate 
 code.
 
 I think this is what you had in mind, and hopefully it will make MST happy 
 too.
 The incremental vhost-scsi patches against Zhi's QEMU are going out shortly 
 ahead
 of cutting a new vhost-scsi RFC over the next days.
 
 Please have a look and let me know if you have any concerns here.
 
 Thanks!
 
 Reported-by: Anthony Liguori aligu...@us.ibm.com
 Cc: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
 Cc: Michael S. Tsirkin m...@redhat.com
 Cc: Paolo Bonzini pbonz...@redhat.com
 Cc: Zhi Yong Wu wu...@linux.vnet.ibm.com
 Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
 ---
  drivers/vhost/tcm_vhost.c |9 +
  drivers/vhost/tcm_vhost.h |   11 +++
  2 files changed, 20 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c
 index dc7e024..3f04169 100644
 --- a/drivers/vhost/tcm_vhost.c
 +++ b/drivers/vhost/tcm_vhost.c
 @@ -977,6 +977,15 @@ static long vhost_scsi_ioctl(struct file *f, unsigned 
 int ioctl,
   return -EFAULT;
  
   return vhost_scsi_clear_endpoint(vs, backend);
 + case VHOST_SCSI_GET_ABI_VERSION:
 + if (copy_from_user(backend, argp, sizeof backend))
 + return -EFAULT;
 +
 + backend.abi_version = VHOST_SCSI_ABI_VERSION;
 +
 + if (copy_to_user(argp, backend, sizeof backend))
 + return -EFAULT;
 + return 0;
   case VHOST_GET_FEATURES:
   features = VHOST_FEATURES;
   if (copy_to_user(featurep, features, sizeof features))
 diff --git a/drivers/vhost/tcm_vhost.h b/drivers/vhost/tcm_vhost.h
 index e942df9..3d5378f 100644
 --- a/drivers/vhost/tcm_vhost.h
 +++ b/drivers/vhost/tcm_vhost.h
 @@ -80,7 +80,17 @@ struct tcm_vhost_tport {
  
  #include linux/vhost.h
  
 +/*
 + * Used by QEMU userspace to ensure a consistent vhost-scsi ABI.
 + *
 + * ABI Rev 0: All pre 2012 revisions used by prototype out-of-tree code
 + * ABI Rev 1: 2012 version for v3.6 kernel merge candiate
 + */
 +
 +#define VHOST_SCSI_ABI_VERSION   1
 +
  struct vhost_scsi_target {
 + int abi_version;
   unsigned char vhost_wwpn[TRANSPORT_IQN_LEN];
   unsigned short vhost_tpgt;
  };
 @@ -88,3 +98,4 @@ struct vhost_scsi_target {
  /* VHOST_SCSI specific defines */
  #define VHOST_SCSI_SET_ENDPOINT _IOW(VHOST_VIRTIO, 0x40, struct 
 vhost_scsi_target)
  #define VHOST_SCSI_CLEAR_ENDPOINT _IOW(VHOST_VIRTIO, 0x41, struct 
 vhost_scsi_target)
 +#define VHOST_SCSI_GET_ABI_VERSION _IOW(VHOST_VIRTIO, 0x42, struct 
 vhost_scsi_target)

No, you just broke the ABI for version 0 here, that's not how you do
this at all.

greg k-h
--
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 16/26] hptiop: avoid buffer overflow when returning sense data

[Greg Kroah-Hartman]

2.6.22-stable review patch.  If anyone has any objections, please let us
know.

--
From: HighPoint Linux Team [EMAIL PROTECTED]

patch 0fec02c93f60fb44ba3a24a0d3e4a52521d34d3f in mainline.

avoid buffer overflow when returning sense data.

With current adapter firmware the driver is working but future firmware
updates may return sense data larger than 96 bytes, causing overflow on
scp-sense_buffer and a kernel crash.

This fix should be backported to earlier kernels.

Signed-off-by: HighPoint Linux Team [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]

---
 drivers/scsi/hptiop.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/scsi/hptiop.c
+++ b/drivers/scsi/hptiop.c
@@ -377,8 +377,9 @@ static void hptiop_host_request_callback
scp-result = SAM_STAT_CHECK_CONDITION;
memset(scp-sense_buffer,
0, sizeof(scp-sense_buffer));
-   memcpy(scp-sense_buffer,
-   req-sg_list, le32_to_cpu(req-dataxfer_length));
+   memcpy(scp-sense_buffer, req-sg_list,
+   min(sizeof(scp-sense_buffer),
+   le32_to_cpu(req-dataxfer_length)));
break;
 
default:

-- 
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 32/40] hptiop: avoid buffer overflow when returning sense data

[Greg Kroah-Hartman]

-stable review patch.  If anyone has any objections, please let us know.

--
From: HighPoint Linux Team [EMAIL PROTECTED]

patch 0fec02c93f60fb44ba3a24a0d3e4a52521d34d3f in mainline.

avoid buffer overflow when returning sense data.

With current adapter firmware the driver is working but future firmware
updates may return sense data larger than 96 bytes, causing overflow on
scp-sense_buffer and a kernel crash.

This fix should be backported to earlier kernels.

Signed-off-by: HighPoint Linux Team [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]

---
 drivers/scsi/hptiop.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/scsi/hptiop.c
+++ b/drivers/scsi/hptiop.c
@@ -365,8 +365,9 @@ static void hptiop_host_request_callback
scp-result = SAM_STAT_CHECK_CONDITION;
memset(scp-sense_buffer,
0, sizeof(scp-sense_buffer));
-   memcpy(scp-sense_buffer,
-   req-sg_list, le32_to_cpu(req-dataxfer_length));
+   memcpy(scp-sense_buffer, req-sg_list,
+   min(sizeof(scp-sense_buffer),
+   le32_to_cpu(req-dataxfer_length)));
break;
 
default:

-- 
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html