Re: [PATCH] megaraid: add scsi_cmnd NULL check before use

2016-05-13 Thread Petros Koutoupis
On Thu, 2016-05-12 at 09:35 +0300, Dan Carpenter wrote: > On Wed, May 11, 2016 at 08:49:51PM -0500, Petros Koutoupis wrote: > > Sumit, > > > > I will resubmit the patch with all the recommendations. Thank you. In case > > you are interested, I have a crash file showcasing the error. I can always >

[PATCH] megaraid: fix error code check of register_chrdev()

2016-05-13 Thread Alexey Khoroshilov
There is invalid error code check of register_chrdev() in megaraid_init(). register_chrdev() returns negative code in case of error, as a result current code can try to unregister_chrdev() with error code instead of major that may lead to unregistering somebody else's chardev. Found by Linux Driv

[PATCH] Fix for hang of Ordered task in TCM

2016-05-13 Thread Michael Cyr
If a command with a Simple task attribute is failed due to a Unit Attention, then a subsequent command with an Ordered task attribute will hang forever. The reason for this is that the Unit Attention status is checked for in target_setup_cmd_from_cdb, before the call to target_execute_cmd, which c

RE: [PATCH] mpt3sas: Do scsi_remove_host() before deleting SAS PHY objects

2016-05-13 Thread Elliott, Robert (Persistent Memory)
> -Original Message- > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Calvin Owens > Sent: Friday, May 13, 2016 3:28 PM ... > Subject: [PATCH] mpt3sas: Do scsi_remove_host() before deleting SAS PHY > objects > ... > The issue is that

[PATCH] mpt3sas: Do scsi_remove_host() before deleting SAS PHY objects

2016-05-13 Thread Calvin Owens
On the hardware I'm testing on, simply removing the mpt3sas module triggers a litany of WARNs culminating in an OOPS: [ cut here ] WARNING: CPU: 5 PID: 13348 at lib/kobject.c:244 kobject_add_internal+0x359/0x8a0 kobject_add_internal failed for ArrayDevice09 (error: -

[PATCH] ses: Fix racy cleanup of /sys in remove_dev()

2016-05-13 Thread Calvin Owens
Currently we free the resources backing the enclosure device before we call device_unregister(). This is racy: during rmmod of low-level SCSI drivers that hook into enclosure, we end up with a small window of time during which writing to /sys can OOPS. Example trace with mpt3sas: general protect

[PATCH] scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands

2016-05-13 Thread James Bottomley
When SCSI was written, all commands coming from the filesystem (REQ_TYPE_FS commands) had data. This meant that our signal for needing to complete the command was the number of bytes completed being equal to the number of bytes in the request. Unfortunately, with the advent of flush barriers, we

Re: [PATCHv3]scsi: don't fail zero length request too early

2016-05-13 Thread James Bottomley
On Fri, 2016-05-13 at 06:51 -0700, James Bottomley wrote: > On Fri, 2016-05-13 at 10:07 +0200, Jinpu Wang wrote: > > Hi James, and all, > > > > I guess you're busy on other staff, so I create patch below as you > > suggested, I think we also need this into stable. > > No, I'll do it, but I just w

Re: [Bug 118081] New: open-iscsi Ping timeout erro

2016-05-13 Thread Mike Christie
On 05/11/2016 10:34 PM, bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=118081 > > Bug ID: 118081 >Summary: open-iscsi Ping timeout erro >Product: SCSI Drivers >Version: 2.5 > Kernel Version: 4.4.7 >

[Bug 118081] open-iscsi Ping timeout erro

2016-05-13 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=118081 --- Comment #1 from Mike Christie --- On 05/11/2016 10:34 PM, bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=118081 > > Bug ID: 118081 >Summary: open-iscsi Ping timeout erro >

Re: [PATCHv3]scsi: don't fail zero length request too early

2016-05-13 Thread James Bottomley
On Fri, 2016-05-13 at 10:07 +0200, Jinpu Wang wrote: > Hi James, and all, > > I guess you're busy on other staff, so I create patch below as you > suggested, I think we also need this into stable. No, I'll do it, but I just wanted to verify that we don't get into an infinite retry loop on any con

RE: [patch 2/2] mpt3sas: clean up indenting a bit

2016-05-13 Thread Chaitra Basappa
Hi Dan, Below patch doesn't apply smoothly on latest upstream kernel , we are seeing Hunk failures. Thanks, Chaitra -Original Message- From: Dan Carpenter [mailto:dan.carpen...@oracle.com] Sent: Friday, May 13, 2016 2:09 AM To: Sathya Prakash Cc: Chaitra P B; Suganath Prabu Subramani; J

RE: [patch 1/2] mpt3sas: add missing curly braces

2016-05-13 Thread Chaitra Basappa
Hi, Please consider this patch as Ack-by: Chaitra P B Thanks, Chaitra -Original Message- From: Dan Carpenter [mailto:dan.carpen...@oracle.com] Sent: Friday, May 13, 2016 2:08 AM To: Sathya Prakash; Chaitra P B Cc: Suganath Prabu Subramani; James E.J. Bottomley; Martin K. Petersen; mpt-

RE: [PATCH] megaraid: add scsi_cmnd NULL check before use

2016-05-13 Thread Finn Thain
On Fri, 13 May 2016, Sumit Saxena wrote: > > For IOs returned by above error are not actually fired to firmware so > there will be no interrupt handler called for the same. You don't need both possibilities to hold. Either one would do it! -- -- To unsubscribe from this list: send the line "

[PATCHv3]scsi: don't fail zero length request too early

2016-05-13 Thread Jinpu Wang
Hi James, and all, I guess you're busy on other staff, so I create patch below as you suggested, I think we also need this into stable. >From 99eab170653544fa1e1bc9511ec055ba70e183d2 Mon Sep 17 00:00:00 2001 From: Jack Wang Date: Fri, 13 May 2016 09:53:21 +0200 Subject: [PATCH] scsi: don't fail

RE: [PATCH] megaraid: add scsi_cmnd NULL check before use

2016-05-13 Thread Sumit Saxena
> -Original Message- > From: Finn Thain [mailto:fth...@telegraphics.com.au] > Sent: Friday, May 13, 2016 1:14 PM > To: Sumit Saxena > Cc: Dan Carpenter; Petros Koutoupis; kashyap.de...@avagotech.com; > sumit.sax...@avagotech.com; uday.ling...@avagotech.com; > megaraidlinux@avagotech.com