Re: [PATCH v1] mpt3sas: Fix calltrace observed while running IO & host reset

2018-06-27 Thread Sreekanth Reddy 
On Thu, Jun 28, 2018 at 3:48 AM, Bart Van Assche  wrote:
> On 06/24/18 23:10, Sreekanth Reddy wrote:
>>
>> Before calling scsi_internal_device_block_nowait() API; driver sets
>> sas_device_priv_data->block flag as one. And in the scsih_qcmd()
>> driver checks for this flag as shown below and return the commands
>> with host busy status.
>>
>> } else if (sas_target_priv_data->tm_busy ||
>>  sas_device_priv_data->block)
>>  return SCSI_MLQUEUE_DEVICE_BUSY;
>
>
> That's exactly the kind of construct that should occur in the SCSI core or
> block layer core and not in a SCSI LLD. Additionally, as explained before,
> the construct you described above is racy.

Can you please elaborate more in details about the racy condition
which you think?
Also if at all is their any racy condition here then we are ready to
work on it separately,
So please consider the fix which we have posted.

Thanks,
Sreekanth




>
> Bart.

[Bug 200317] New: Null pointer dereference error in linux/drivers/scsi/scsi_transport_fc.c

2018-06-27 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=200317

Bug ID: 200317
   Summary: Null pointer dereference error in
linux/drivers/scsi/scsi_transport_fc.c
   Product: SCSI Drivers
   Version: 2.5
Kernel Version: 4.17.3
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Other
  Assignee: scsi_drivers-ot...@kernel-bugs.osdl.org
  Reporter: wangyxla...@gmail.com
Regression: No

In function fc_eh_timed_out , which is defined in
linux/drivers/scsi/scsi_transport_fc.c

2083-2086,
struct fc_rport *rport = starget_to_rport(scsi_target(scmd->device));

if (rport->port_state == FC_PORTSTATE_BLOCKED)
return BLK_EH_RESET_TIMER;

starget_to_rport is a macro defined in linux/include/scsi/scsi_transport_fc.h,

#define starget_to_rport(s) \
scsi_is_fc_rport(s->dev.parent) ? dev_to_rport(s->dev.parent) : NULL

Since starget_to_rport may return a NULL value, the variable rport may be
assigned NULL. Thus there is a potential Null Pointer Deref error in if
(rport->port_state == FC_PORTSTATE_BLOCKED). There should be a NULL value check
for rport .

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Re: mpt3sas regression...

2018-06-27 Thread David Miller 
From: Chaitra Basappa 
Date: Wed, 27 Jun 2018 19:58:34 +0530

>  Please let us know what is the issue faced and  if its recreating then
> share the driver logs with logging_level=0x3f8.

The driver cannot even probe successfully to start scanning for disks
because some busy bit never clears.  I think it was in one of the
firmware status registers or the doorbell register.

Re: Possible race in completion with SRP after abort with latest upstream kernel 4.17.0+

2018-06-27 Thread Bart Van Assche 

On 06/07/18 08:34, Laurence Oberman wrote:

On Thu, 2018-06-07 at 15:21 +, Bart Van Assche wrote:

On Thu, 2018-06-07 at 09:23 -0400, Laurence Oberman wrote:

Have you seen this before, let me know what else you want from the
dump while I look further.


Hello Laurence,

I haven't seen this before and I can't reproduce this by running srp-
tests against Linus' latest master. So it would be appreciated if you could
tell me how to reproduce this behavior or if you could run a bisect.


OK, let me see if I can get it to fail reliably to narrow it down.


Hello Laurence,

In the kernel oops report I found  v4.17.0+ as kernel version. Is that 
kernel v4.17 with some patches applied or rather a kernel close to 
v4.18-rc1? Since the v4.18 merge window closed several bug fixes have 
been merged upstream for the block layer.


Thanks,

Bart.

Re: [PATCH v1] mpt3sas: Fix calltrace observed while running IO & host reset

2018-06-27 Thread Bart Van Assche 

On 06/24/18 23:10, Sreekanth Reddy wrote:

Before calling scsi_internal_device_block_nowait() API; driver sets
sas_device_priv_data->block flag as one. And in the scsih_qcmd()
driver checks for this flag as shown below and return the commands
with host busy status.

} else if (sas_target_priv_data->tm_busy ||
 sas_device_priv_data->block)
 return SCSI_MLQUEUE_DEVICE_BUSY;


That's exactly the kind of construct that should occur in the SCSI core 
or block layer core and not in a SCSI LLD. Additionally, as explained 
before, the construct you described above is racy.


Bart.

RE: aacraid driver, kernel 4.14 and up, ASR8xxx controller : doesn't work

2018-06-27 Thread Dave Carroll 



> -Original Message-
> From: Dave Carroll
> Sent: Wednesday, June 27, 2018 12:46 PM
> To: Emmanuel Florac ; linux-scsi@vger.kernel.org
> Cc: dl-esc-Aacraid Linux Driver 
> Subject: RE: aacraid driver, kernel 4.14 and up, ASR8xxx controller : doesn't 
> work
> 
> Hi Emmanual,
> 
> > [  346.869001] scsi host6: aacraid
> > [  346.869500] scsi 6:0:2:0: Direct-Access ASR8885  raid3
> > V1.0 PQ: 0
> > ANSI: 2
> > [  346.869692] sd 6:0:2:0: [sdb] Very big device. Trying to use READ
> > CAPACITY(16).
> > [  346.869712] sd 6:0:2:0: [sdb] 632763166720 512-byte logical blocks:
> > (324
> > TB/295 TiB)
> 
> Is this size consistent with the 4.13 kernel? That size is greater than the 
> 64-bit
> LBA addressing (0x93 539F B000).

Sorry, that comment was incorrect, but I would like to see if the size is 
consistent between the kernels.

Thanks, -Dave
> -

RE: aacraid driver, kernel 4.14 and up, ASR8xxx controller : doesn't work

2018-06-27 Thread Dave Carroll 
Hi Emmanual,

> [  346.869001] scsi host6: aacraid
> [  346.869500] scsi 6:0:2:0: Direct-Access ASR8885  raid3V1.0 
> PQ: 0
> ANSI: 2
> [  346.869692] sd 6:0:2:0: [sdb] Very big device. Trying to use READ
> CAPACITY(16).
> [  346.869712] sd 6:0:2:0: [sdb] 632763166720 512-byte logical blocks: (324
> TB/295 TiB)

Is this size consistent with the 4.13 kernel? That size is greater than the 
64-bit LBA addressing (0x93 539F B000).
Can you give the dmesg output from the working kernel? Not quite sure where the 
extra size came from ...

Thanks, -Dave
-

Re: aacraid driver, kernel 4.14 and up, ASR8xxx controller : doesn't work

2018-06-27 Thread Emmanuel Florac 
Le Wed, 27 Jun 2018 18:20:27 +0200
Emmanuel Florac  écrivait:

> As per my previous post, I've determined that the aacraid driver
> doesn't work with current Adaptec RAID controllers (ASR8xxx family,
> latest firmware) with kernels over 4.14. Kernel up to 4.15 works with
> ASR7xxx family but kernel 4.16 doesn't work either with ASR7xxx nor
> ASR8xxx controllers.
> 
> I've just retried running the latest 4.16.18 (plain vanilla) on Debian
> stable:
> 
> Running "modprobe aacraid", the driver hangs and resets the controller
> constantly. rebooting the system on earlier kernels up to 4.13.xx
> everything *just works* without any problem. dmesg output:
> 
> [  344.845719] Adaptec aacraid driver 1.2.1[50877]-custom
> [  344.852250] aacraid: Comm Interface type2 enabled
> [  344.859381] AAC0: kernel 7.13-0[33263] Mar 16 2018
> [  344.859384] AAC0: monitor 7.13-0[33263]
> [  344.859385] AAC0: bios 7.13-0[33263]
> [  344.859388] AAC0: serial 6A476396945
> [  344.859389] AAC0: Non-DASD support enabled.
> [  346.869001] scsi host6: aacraid
> [  346.869500] scsi 6:0:2:0: Direct-Access ASR8885

For comparison, here's the output booting 4.13.16 (the highest working
release) on the same system ; driver version is slightly different:

[5.762727] Adaptec aacraid driver 1.2.1[50834]-custom
[5.768147] aacraid: Comm Interface type2 enabled
[5.775262] AAC0: kernel 7.13-0[33263] Mar 16 2018
[5.775264] AAC0: monitor 7.13-0[33263]
[5.775265] AAC0: bios 7.13-0[33263]
[5.775267] AAC0: serial 6A476396945
[5.775268] AAC0: Non-DASD support enabled.
[7.782209] scsi host6: aacraid
[7.782629] scsi 6:0:2:0: Direct-Access ASR8885  raid3V1.0 
PQ: 0 ANSI: 2
[7.782735] sd 6:0:2:0: [sdb] Very big device. Trying to use READ 
CAPACITY(16).
[7.782743] sd 6:0:2:0: [sdb] 632763166720 512-byte logical blocks: (324 
TB/295 TiB)
[7.782751] sd 6:0:2:0: [sdb] Write Protect is off
[7.782752] sd 6:0:2:0: [sdb] Mode Sense: 12 00 10 08
[7.782764] sd 6:0:2:0: [sdb] Write cache: disabled, read cache: enabled, 
supports DPO and FUA
[7.782832] sd 6:0:2:0: [sdb] Very big device. Trying to use READ 
CAPACITY(16).
[7.808366] scsi 6:1:105:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.809387] scsi 6:1:106:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.810895] scsi 6:1:107:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.811889] scsi 6:1:108:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.812131] sd 6:0:2:0: [sdb] Very big device. Trying to use READ 
CAPACITY(16).
[7.812156] sd 6:0:2:0: [sdb] Attached SCSI removable disk
[7.812884] scsi 6:1:109:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.813886] scsi 6:1:110:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.814861] scsi 6:1:111:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.815994] scsi 6:1:112:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.817001] scsi 6:1:113:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.818019] scsi 6:1:114:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.819004] scsi 6:1:115:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.820103] scsi 6:1:116:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.821087] scsi 6:1:117:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.822065] scsi 6:1:118:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.824714] scsi 6:1:119:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.825785] scsi 6:1:120:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.826830] scsi 6:1:121:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.829031] scsi 6:1:122:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.830013] scsi 6:1:123:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.831022] scsi 6:1:124:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.832033] scsi 6:1:125:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.833098] scsi 6:1:126:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.834078] scsi 6:1:127:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.835077] scsi 6:1:128:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.836046] scsi 6:1:129:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.837025] scsi 6:1:130:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.838002] scsi 6:1:131:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.838984] scsi 6:1:132:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[7.839965] scsi

aacraid driver, kernel 4.14 and up, ASR8xxx controller : doesn't work

2018-06-27 Thread Emmanuel Florac 

As per my previous post, I've determined that the aacraid driver
doesn't work with current Adaptec RAID controllers (ASR8xxx family,
latest firmware) with kernels over 4.14. Kernel up to 4.15 works with
ASR7xxx family but kernel 4.16 doesn't work either with ASR7xxx nor
ASR8xxx controllers.

I've just retried running the latest 4.16.18 (plain vanilla) on Debian
stable:

Running "modprobe aacraid", the driver hangs and resets the controller
constantly. rebooting the system on earlier kernels up to 4.13.xx
everything *just works* without any problem. dmesg output:

[  344.845719] Adaptec aacraid driver 1.2.1[50877]-custom
[  344.852250] aacraid: Comm Interface type2 enabled
[  344.859381] AAC0: kernel 7.13-0[33263] Mar 16 2018
[  344.859384] AAC0: monitor 7.13-0[33263]
[  344.859385] AAC0: bios 7.13-0[33263]
[  344.859388] AAC0: serial 6A476396945
[  344.859389] AAC0: Non-DASD support enabled.
[  346.869001] scsi host6: aacraid
[  346.869500] scsi 6:0:2:0: Direct-Access ASR8885  raid3V1.0 
PQ: 0 ANSI: 2
[  346.869692] sd 6:0:2:0: [sdb] Very big device. Trying to use READ 
CAPACITY(16).
[  346.869712] sd 6:0:2:0: [sdb] 632763166720 512-byte logical blocks: (324 
TB/295 TiB)
[  346.869727] sd 6:0:2:0: [sdb] Write Protect is off
[  346.869730] sd 6:0:2:0: [sdb] Mode Sense: 12 00 10 08
[  346.869750] sd 6:0:2:0: [sdb] Write cache: disabled, read cache: enabled, 
supports DPO and FUA
[  346.870431] sd 6:0:2:0: Attached scsi generic sg1 type 0
[  346.870455] sd 6:0:2:0: [sdb] Very big device. Trying to use READ 
CAPACITY(16).
[  346.895430] scsi 6:1:105:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.896058] scsi 6:1:105:0: Attached scsi generic sg2 type 0
[  346.897159] scsi 6:1:106:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.897844] scsi 6:1:106:0: Attached scsi generic sg3 type 0
[  346.898803] scsi 6:1:107:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.899805] scsi 6:1:107:0: Attached scsi generic sg4 type 0
[  346.900583] scsi 6:1:108:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.901280] scsi 6:1:108:0: Attached scsi generic sg5 type 0
[  346.902491] scsi 6:1:109:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.907440] scsi 6:1:109:0: Attached scsi generic sg6 type 0
[  346.908035] scsi 6:1:110:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.909257] scsi 6:1:110:0: Attached scsi generic sg7 type 0
[  346.910633] scsi 6:1:111:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.911878] scsi 6:1:111:0: Attached scsi generic sg8 type 0
[  346.912630] scsi 6:1:112:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.913303] scsi 6:1:112:0: Attached scsi generic sg9 type 0
[  346.914150] scsi 6:1:113:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.914888] scsi 6:1:113:0: Attached scsi generic sg10 type 0
[  346.915664] scsi 6:1:114:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.916388] scsi 6:1:114:0: Attached scsi generic sg11 type 0
[  346.917536] scsi 6:1:115:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.918256] scsi 6:1:115:0: Attached scsi generic sg12 type 0
[  346.919351] scsi 6:1:116:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.921804] scsi 6:1:116:0: Attached scsi generic sg13 type 0
[  346.922346] scsi 6:1:117:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.922909] scsi 6:1:117:0: Attached scsi generic sg14 type 0
[  346.923629] scsi 6:1:118:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.924213] scsi 6:1:118:0: Attached scsi generic sg15 type 0
[  346.925151] scsi 6:1:119:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.925809] scsi 6:1:119:0: Attached scsi generic sg16 type 0
[  346.926642] scsi 6:1:120:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.927243] scsi 6:1:120:0: Attached scsi generic sg17 type 0
[  346.927801] scsi 6:1:121:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.928452] scsi 6:1:121:0: Attached scsi generic sg18 type 0
[  346.928992] scsi 6:1:122:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.929689] scsi 6:1:122:0: Attached scsi generic sg19 type 0
[  346.930245] scsi 6:1:123:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.930953] scsi 6:1:123:0: Attached scsi generic sg20 type 0
[  346.931641] scsi 6:1:124:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.932280] scsi 6:1:124:0: Attached scsi generic sg21 type 0
[  346.933558] scsi 6:1:125:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ: 1 ANSI: 6
[  346.934181] scsi 6:1:125:0: Attached scsi generic sg22 type 0
[  346.934724] scsi 6:1:126:0: Direct-Access HGST HUH721212AL5200  A3D0 
PQ:

RE: mpt3sas regression...

2018-06-27 Thread Chaitra Basappa 
David,
 Please let us know what is the issue faced and  if its recreating then
share the driver logs with logging_level=0x3f8.

Thanks,
 Chaitra


-Original Message-
From: Chaitra Basappa [mailto:chaitra.basa...@broadcom.com]
Sent: Tuesday, June 26, 2018 5:36 PM
To: David Miller; linux-scsi@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Subject: RE: mpt3sas regression...

Hi David,
 Sorry for the inconvenience caused. Yes,  "scsi: mpt3sas: Bug fix for big
endian systems." patch was posted to fix sparse warnings.
I missed the testing. Currently we are testing on sparc64 system and soon
I will be reposting the patch based on the findings.

Thanks,
 Chaitra


-Original Message-
From: David Miller [mailto:da...@davemloft.net]
Sent: Sunday, June 24, 2018 10:17 AM
To: linux-scsi@vger.kernel.org
Cc: chaitra.basa...@broadcom.com; sparcli...@vger.kernel.org
Subject: mpt3sas regression...


Commit:


commit cf6bf9710cabba1fe94a4349f4eb8db623c77ebc
Author: Chaitra P B 
Date:   Tue Apr 24 05:28:30 2018 -0400

scsi: mpt3sas: Bug fix for big endian systems.


actually breaks big-endian.  This driver has been working perfectly
fine for more a decade or so on my sparc64 test systems up until this
point.

If you are just responding to sparse warnings, please do not do that.
What big-endian system did you test this change on?

Meanwhile, I'd like to ask that this change be reverted.

Thank you.

Re: [PATCH 2/2] qedi: Fix truncation of target name

2018-06-27 Thread Bart Van Assche 
On Wed, 2018-06-27 at 05:14 -0700, Nilesh Javali wrote:
> Use sprintf instead of snprintf to fix truncation of target name.
> This fix is extension of patch
> "scsi: qedi: Fix truncation of CHAP name and secret".
> 
> Signed-off-by: Nilesh Javali 
> ---
>  drivers/scsi/qedi/qedi_main.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/qedi_main.c
> index cf274a7..85491da 100644
> --- a/drivers/scsi/qedi/qedi_main.c
> +++ b/drivers/scsi/qedi/qedi_main.c
> @@ -888,8 +888,8 @@ static void qedi_get_boot_tgt_info(struct nvm_iscsi_block 
> *block,
>   ipv6_en = !!(block->generic.ctrl_flags &
>NVM_ISCSI_CFG_GEN_IPV6_ENABLED);
>  
> - snprintf(tgt->iscsi_name, NVM_ISCSI_CFG_ISCSI_NAME_MAX_LEN, "%s\n",
> -  block->target[index].target_name.byte);
> + sprintf(tgt->iscsi_name, "%.*s\n", NVM_ISCSI_CFG_ISCSI_NAME_MAX_LEN,
> + block->target[index].target_name.byte);
>  
>   tgt->ipv6_en = ipv6_en;

Also this patch changes code that is fine into code that can trigger a buffer
overflow. Additionally, for humans it is much harder than necessary to verify
the above code. Please consider to use sizeof(tgt->iscsi_name) - 2 instead of
NVM_ISCSI_CFG_ISCSI_NAME_MAX_LEN.

Thanks,

Bart.

Re: [PATCH 1/2] qedi: Correct the size of target name

2018-06-27 Thread Bart Van Assche 
On Wed, 2018-06-27 at 05:14 -0700, Nilesh Javali wrote:
> There is potential buffer overflow while getting the target
> name from the NVRAM. Correct the size of the buffer to avoid
> overflow.
> 
> Signed-off-by: Nilesh Javali 
> ---
>  drivers/scsi/qedi/qedi_iscsi.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/qedi/qedi_iscsi.h b/drivers/scsi/qedi/qedi_iscsi.h
> index 1126077..d690330 100644
> --- a/drivers/scsi/qedi/qedi_iscsi.h
> +++ b/drivers/scsi/qedi/qedi_iscsi.h
> @@ -225,7 +225,7 @@ struct qedi_work_map {
>  
>  struct qedi_boot_target {
>   char ip_addr[64];
> - char iscsi_name[255];
> + char iscsi_name[256];
>   u32 ipv6_en;
>  };

Has the number 256 perhaps been derived from the following paragraph
in the iSCSI spec? If so, please mention this in the patch description.
From https://tools.ietf.org/html/rfc3720:

   If not otherwise specified, the maximum length of a simple-value (not
   its encoded representation) is 255 bytes, not including the delimiter
   (comma or zero byte).

Thanks,

Bart.

[Bug 200307] Read only file system after failed suspend

2018-06-27 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=200307

--- Comment #3 from Antonín Dach (d...@protonmail.com) ---
Created attachment 276921
  --> https://bugzilla.kernel.org/attachment.cgi?id=276921=edit
kernel config

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 200307] Read only file system after failed suspend

2018-06-27 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=200307

--- Comment #2 from Antonín Dach (d...@protonmail.com) ---
Created attachment 276919
  --> https://bugzilla.kernel.org/attachment.cgi?id=276919=edit
lshw -short

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 200307] Read only file system after failed suspend

2018-06-27 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=200307

--- Comment #1 from Antonín Dach (d...@protonmail.com) ---
Created attachment 276917
  --> https://bugzilla.kernel.org/attachment.cgi?id=276917=edit
inix

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 200307] New: Read only file system after failed suspend

2018-06-27 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=200307

Bug ID: 200307
   Summary: Read only file system after failed suspend
   Product: SCSI Drivers
   Version: 2.5
Kernel Version: 4.17.0 MANJARO flavor ( vanilla with custom config )
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Other
  Assignee: scsi_drivers-ot...@kernel-bugs.osdl.org
  Reporter: d...@protonmail.com
Regression: No

Created attachment 276915
  --> https://bugzilla.kernel.org/attachment.cgi?id=276915=edit
screenshot of journalctl, failed suspension

Hi, 

There's a new issue with new kernel 4.17 ( is not happening on 4.16 and prior )


My AMD system with Mobo: Gigabyte model: F2A88XN-WIFI rev.3 fails to suspend.
More inxi system information in attachment.

I can clearly see a power down on main Power LED but system often fails to
remain in suspension and wakes cca a quater second later. 

The woken system is completely unuseable as every drive (except ramdisk) is
rendered Read only.

I can't post the enitre journal as it fails to launch and is never written. I
was lucky enough to have tail on journal once so I took and photo of my screen.
( please do not hate I had not idea how export the journal as no command would
run on READONLY FS) 


IOMMU is disabled.
Not using RAID.

 $ lsscsi
[0:0:0:0]diskATA  INTEL SSDSC2BW24 RG21  /dev/sda 
[1:0:0:0]diskATA  WDC WD5003AZEX-0 1A01  /dev/sdb

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 2/2] qedi: Fix truncation of target name

2018-06-27 Thread Nilesh Javali 
Use sprintf instead of snprintf to fix truncation of target name.
This fix is extension of patch
"scsi: qedi: Fix truncation of CHAP name and secret".

Signed-off-by: Nilesh Javali 
---
 drivers/scsi/qedi/qedi_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/qedi_main.c
index cf274a7..85491da 100644
--- a/drivers/scsi/qedi/qedi_main.c
+++ b/drivers/scsi/qedi/qedi_main.c
@@ -888,8 +888,8 @@ static void qedi_get_boot_tgt_info(struct nvm_iscsi_block 
*block,
ipv6_en = !!(block->generic.ctrl_flags &
 NVM_ISCSI_CFG_GEN_IPV6_ENABLED);
 
-   snprintf(tgt->iscsi_name, NVM_ISCSI_CFG_ISCSI_NAME_MAX_LEN, "%s\n",
-block->target[index].target_name.byte);
+   sprintf(tgt->iscsi_name, "%.*s\n", NVM_ISCSI_CFG_ISCSI_NAME_MAX_LEN,
+   block->target[index].target_name.byte);
 
tgt->ipv6_en = ipv6_en;
 
-- 
1.8.3.1

[PATCH 0/2] Bug fixes for static checker warnings

2018-06-27 Thread Nilesh Javali 
Martin,
Please consider below patch set for next 'scsi-fixes' submission.

Thanks,
Nilesh

Nilesh Javali (2):
  qedi: Correct the size of target name
  qedi: Fix truncation of target name

 drivers/scsi/qedi/qedi_iscsi.h | 2 +-
 drivers/scsi/qedi/qedi_main.c  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
1.8.3.1

[PATCH 1/2] qedi: Correct the size of target name

2018-06-27 Thread Nilesh Javali 
There is potential buffer overflow while getting the target
name from the NVRAM. Correct the size of the buffer to avoid
overflow.

Signed-off-by: Nilesh Javali 
---
 drivers/scsi/qedi/qedi_iscsi.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/qedi/qedi_iscsi.h b/drivers/scsi/qedi/qedi_iscsi.h
index 1126077..d690330 100644
--- a/drivers/scsi/qedi/qedi_iscsi.h
+++ b/drivers/scsi/qedi/qedi_iscsi.h
@@ -225,7 +225,7 @@ struct qedi_work_map {
 
 struct qedi_boot_target {
char ip_addr[64];
-   char iscsi_name[255];
+   char iscsi_name[256];
u32 ipv6_en;
 };
 
-- 
1.8.3.1

Re: [PATCH-next] scsi: libsas: dynamically allocate and free ata host

2018-06-27 Thread John Garry 

On 26/06/2018 17:40, Martin K. Petersen wrote:


John,


Took a while for all the prerequisites to materialize. I just rebased
4.19/scsi-queue to v4.18-rc1 and applied your patch. Thanks!


Is it possible to add this patch to the 4.18 fixes?


I was on the fence on this but felt it was an intricate enough change to
warrant a bit of soak time before ending up in a stable release. That's
why it went into 4.19.



Hi Martin,

OK, but please be aware that there may be a more serious issue fixed 
here than the WARN, in that we could try to free memory embedded in a 
structure.


Thanks,
John