Re: [PATCH 24/24] osst: add a SPDX tag to osst.c

2019-05-09 Thread Willem Riede 
On Thu, May 2, 2019 at 7:19 AM Hannes Reinecke  wrote:

> On 5/2/19 2:53 PM, Christoph Hellwig wrote:
> > On Thu, May 02, 2019 at 08:06:38AM +0200, Hannes Reinecke wrote:
> >> On 5/1/19 6:14 PM, Christoph Hellwig wrote:
> >>> osst.c is the only osst file missing licensing information.  Add a
> >>> GPLv2 tag for the default kernel license.
> >>>
> >>> Signed-off-by: Chriosstoph Hellwig 
> >
> > FYI, my s/st/osst/ on the commit message message up my signoff, this
> > should be:
> >
> > Signed-off-by: Christoph Hellwig 
> >
> Maybe it's time to kill osst.c for good ...
>

Yes. I've been thinking about doing just that. The devices it supports are
now thoroughly obsolete. The manufacturer has gone out of business. All my
test drives have broken down over time, so I can't even test any changes
any more.

Regards, Willem Riede, osst maintainer.


> Cheers,
>
> Hannes
> --
> Dr. Hannes ReineckeTeamlead Storage & Networking
> h...@suse.de   +49 911 74053 688
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
> HRB 21284 (AG Nürnberg)
>

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/CAKnBiiaSyW27tCqU4i6zStF3AoLPcndSL2gjz1b17LdoFddiiw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 24/24] osst: add a SPDX tag to osst.c

2019-05-09 Thread Willem Riede 
On Fri, May 3, 2019 at 1:05 AM Hannes Reinecke  wrote:

> On 5/2/19 9:55 PM, Willem Riede wrote:
> > On Thu, May 2, 2019 at 7:19 AM Hannes Reinecke  > > wrote:
> >
> >  >
> > Maybe it's time to kill osst.c for good ...
> >
> >
> > Yes. I've been thinking about doing just that. The devices it supports
> > are now thoroughly obsolete. The manufacturer has gone out of business.
> > All my test drives have broken down over time, so I can't even test any
> > changes any more.
> >
> Just when I thought to reach out to you :-)
>
> Thing is, we've done numerous changes to the 'st' driver in the course
> of the years, most of which seem to have avoided osst :-(
>
> So what's your suggestion here?
> Just drop it completely?
> Or can we somehow fold the OnStream-specific things back into st.c?
>
> I sincerely doubt anyone in the entire world still has an Onstream drive
working.
These days cheap flash drives have larger capacity and are way more
convenient.

I recommend to drop osst entirely and not to contaminate st.

Regards, Willem Riede.



> Cheers,
>
> Hannes
> --
> Dr. Hannes ReineckeTeamlead Storage & Networking
> h...@suse.de   +49 911 74053 688
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
> HRB 21284 (AG Nürnberg)
>

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/CAKnBiiYqwPNFU709s8bb%2BUhX18oqkTRyHpkO2pBAenisHiPUig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 17/24] libsas: switch remaining files to SPDX tags

2019-05-09 Thread John Garry 

On 01/05/2019 17:14, Christoph Hellwig wrote:

Use the the GPLv2 SPDX tag instead of verbose boilerplate text.



Should we update the Kconfig+Makefile similarly?


Signed-off-by: Christoph Hellwig 
---
 drivers/scsi/libsas/sas_discover.c  | 18 +-
 drivers/scsi/libsas/sas_event.c | 18 +-
 drivers/scsi/libsas/sas_expander.c  | 16 +---
 drivers/scsi/libsas/sas_host_smp.c  |  5 +
 drivers/scsi/libsas/sas_init.c  | 19 +--
 drivers/scsi/libsas/sas_internal.h  | 19 +--
 drivers/scsi/libsas/sas_phy.c   | 18 +-
 drivers/scsi/libsas/sas_port.c  | 18 +-
 drivers/scsi/libsas/sas_scsi_host.c | 19 +--
 include/scsi/libsas.h   | 19 +--
 include/scsi/sas.h  | 19 +--
 include/scsi/sas_ata.h  | 17 +
 12 files changed, 12 insertions(+), 193 deletions(-)

diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c


...


 #include 
diff --git a/drivers/scsi/libsas/sas_expander.c 
b/drivers/scsi/libsas/sas_expander.c
index 83f2fd70ce76..76ea83ddafa7 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Serial Attached SCSI (SAS) Expander discovery and configuration
  *
@@ -5,21 +6,6 @@
  * Copyright (C) 2005 Luben Tuikov 
  *
  * This file is licensed under GPLv2.


Was this just missed?


- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
- *
  */





--
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/c049de31-eff4-28b2-f4dc-4db2205895d2%40huawei.com.
For more options, visit https://groups.google.com/d/optout.

Re: [bug report][scsi blk_mq] data corruption due to a bug in SCSI LLD error handling

2019-05-09 Thread The Lee-Man 
I think the point is that the sg path is not equal to the real IO path. You 
are (currently) never going to get correct error handling from the sg path, 
which is considered out of band.

So what are you trying to do here? Are you really developing software that 
uses the sg path, and you need this to work, or are you testing the error 
handling and decided to use sg? In other words, is this a real bug, or just 
something you think should work but does not?

On Tuesday, April 9, 2019 at 5:36:42 PM UTC-4, Jaesoo Lee wrote:
>
> Hi, 
>
> Thanks for the comments. 
>
> I tried to run sg_write_same over sg device and I am seeing the same 
> problem. 
>
> The result is as follows: 
>
> 0. Kernel configs 
> Version: 5.1-rc1 
> Boot parameter: dm_mod.use_blk_mq=Y scsi_mod.use_blk_mq=Y 
>
> 1. Normal state 
> : (As expected) The command succeeded 
>
> $ sg_write_same --lba=100 --xferlen=512 /dev/sg5 
> $ 
>
> 2. Immediately after bringing down the iSCSI interface at the target 
> : (As expected) Failed with DID_TRANSPORT_DISRUPTED after a few seconds 
>
> $ sg_write_same --lba=100 --xferlen=512 /dev/sg5 
> Write same: transport: Host_status=0x0e [DID_TRANSPORT_DISRUPTED] 
> Driver_status=0x00 [DRIVER_OK, SUGGEST_OK] 
>
> Write same(10) command failed 
>
> 3. Immediately after the DID_TRANSPORT_DISRUPTED error 
> : (BUG) The command succeeded after a few seconds 
>
> $ sg_write_same --lba=100 --xferlen=512 /dev/sg5 
> $ 
>
> : Kernel logs 
> Apr  8 18:28:03 init21-16 kernel: session1: session recovery timed out 
> after 10 secs 
> Apr  8 18:28:03 init21-16 kernel: sd 8:0:0:5: rejecting I/O to offline 
> device 
>
> 4. Issued IO again 
> : (As expected) The command failed 
>
> $ sg_write_same --lba=100 --xferlen=512 /dev/sg5 
> Write same: pass through os error: No such device or address 
> Write same(10) command failed 
>
> Let me upload my fix for this and please give me some comments on that. 
>
> Thanks, 
>
> Jaesoo Lee. 
>
> -- Forwarded message - 
> From: Douglas Gilbert 
> Date: Wed, Apr 3, 2019 at 2:06 PM 
> Subject: Re: [bug report][scsi blk_mq] data corruption due to a bug in 
> SCSI LLD error handling 
> To: <...>
>
>
> On 2019-04-03 4:18 p.m., Jaesoo Lee wrote: 
> > Hello All, 
> > 
> > I encountered this bug while trying to enable dm_blk_mq for our 
> > iSCSI/FCP targets. 
> > 
> > The bug is that the sg_io issued to scsi_blk_mq would succeed even if 
> > LLD wants to error out those requests. 
> > 
> > Let me explain the scenario in more details. 
> > 
> > Setup: 
> > 0. Host kernel configuration 
> > - 4.19.9, 4.20.16 
> > - boot parameter: dm_mod.use_blk_mq=Y scsi_mod.use_blk_mq=Y 
> > scsi_transport_iscsi.debug_session=1 scsi_transport_iscsi.debug_conn=1 
> > 
> > Scenario: 
> > 1. Connect the host to iSCSI target via four paths 
> > : A dm device is created for those target devices 
> > 2. Start an application in the host which generates sg_io ioctl for 
> > XCOPY and WSAME to the dm device with the ratio of around 50% 
> > (pread/pwrite for the rest). 
> > 3. Perform system crash (sysrq-trigger) in the iSCSI target 
> > 
> > Expected result: 
> > - Any outstanding IOs should get failed with errors 
> > 
> > Actual results: 
> > - Normal read/write IOs get failed as expected 
> > - SG_IO ioctls SUCCEEDED!! 
>
> Not all ioctl(SG_IO)s are created equal! 
>
> If you are using the sg v3 interface (i.e. struct sg_io_hdr) then I would 
> expect DRIVER_TIMEOUT in sg_io_obj.driver_status or DID_TIME_OUT in 
> sg_io_obj.host_status to be set on completion. [BTW You will _not_ see 
> a ETIMEDOUT errno; only errors prior to submission yield errno style 
> errors.] 
>
> If you don't see that with ioctl(SG_IO) on a block device then try again 
> on 
> a sg device. If neither report that then the mid-level error processing 
> is broken. 
>
> Doug Gilbert 
>
>
> > - log message: 
> > [Tue Apr  2 11:26:34 2019]  session3: session recovery timed out after 
> 11 secs 
> > [Tue Apr  2 11:26:34 2019]  session3: session_recovery_timedout: 
> > Unblocking SCSI target 
> > .. 
> > [Tue Apr  2 11:26:34 2019] sd 8:0:0:8: scsi_prep_state_check: 
> > rejecting I/O to offline device 
> > [Tue Apr  2 11:26:34 2019] sd 8:0:0:8: scsi_prep_state_check: 
> > rejecting I/O to offline device 
> > [Tue Apr  2 11:26:34 2019] sd 8:0:0:8: scsi_prep_state_check: 
> > rejecting I/O to offline device 
> > [Tue Apr  2 11:26:34 2019] print_req_error: I/O error, dev sdi, sector 
> 30677580 
> > [Tue Apr  2 11:26:34 2019] device-mapper: multipath: Failing path 8:128. 
> > [Tue Apr  2 11:26:34 2019] SG_IO disk=sdi, result=0x0 
> > 
> > - This causes the DATA corruption for the application 
> > 
> > Relavant call stacks: (SG_IO issue path) 
> > [Tue Apr  2 11:26:33 2019] sd 8:0:0:8: [sdi] sd_ioctl: disk=sdi, 
> cmd=0x2285 
> > [Tue Apr  2 11:26:33 2019] SG_IO disk=sdi, retried 1 cmd 93 
> > [Tue Apr  2 11:26:33 2019] CPU: 30 PID: 16080 Comm: iostress Not 
> > tainted 4.19.9-purekernel_dbg.x86_64+ #30 
> > [Tue Apr  2 11:26:33