On Tue, 16 Jan 2024 12:58:36 +0800, Li RongQing wrote:
> virtqueue_enable_cb() will call virtqueue_poll() which will check if
> queue is broken at beginning, so remove the virtqueue_is_broken() call
>
>
Applied to 6.8/scsi-fixes, thanks!
[1/1] virtio_scsi: remove duplicate check if queue is br
> virtqueue_enable_cb() will call virtqueue_poll() which will check if
> queue is broken at beginning, so remove the virtqueue_is_broken() call
Applied to 6.8/scsi-staging, thanks!
--
Martin K. Petersen Oracle Linux Engineering
On Tue, Jan 16, 2024 at 12:58:36PM +0800, Li RongQing wrote:
> virtqueue_enable_cb() will call virtqueue_poll() which will check if
> queue is broken at beginning, so remove the virtqueue_is_broken() call
>
> Signed-off-by: Li RongQing
Acked-by: Michael S. Tsirkin
> ---
> drivers/scsi/virtio
On Tue, 16 Jan 2024 at 00:07, Li RongQing wrote:
>
> virtqueue_enable_cb() will call virtqueue_poll() which will check if
> queue is broken at beginning, so remove the virtqueue_is_broken() call
>
> Signed-off-by: Li RongQing
> ---
> drivers/scsi/virtio_scsi.c | 2 --
> 1 file changed, 2 deletio
On Tue, Oct 22, 2019 at 10:02 AM Sudarsana Reddy Kalluru
wrote:
>
> This patch adds new FW for bnx2x, which addresses the following issues:
> - TCP packet with padding can open TPA aggregation in GRO mode.
> - Tx Silent Drops could cause HW error when statistics is not enabled for
> client.
> - T
On 09/10/2019 10:32, Ming Lei wrote:
It isn't necessary to check the host depth in scsi_queue_rq() any more
since it has been respected by blk-mq before calling scsi_queue_rq() via
getting driver tag.
Lots of LUNs may attach to same host and per-host IOPS may reach millions,
so we should avoid e
V4 2/2] scsi: core: don't limit per-LUN queue depth
> for SSD
>
> On Fri, Oct 18, 2019 at 12:00:07AM +0530, Kashyap Desai wrote:
> > > On 10/9/19 2:32 AM, Ming Lei wrote:
> > > > @@ -354,7 +354,8 @@ void scsi_device_unbusy(struct scsi_device
> > > > *sdev,
> > > struct scsi_cmnd *cmd)
> > > >
On 2019/10/22 9:59, zhengbin (A) wrote:
> On 2019/10/21 21:06, Hannes Reinecke wrote:
>> On 10/21/19 3:49 AM, zhengbin (A) wrote:
>>> On 2019/10/18 21:43, Martin K. Petersen wrote:
Hannes,
> The one thing which I patently don't like is the ambivalence between
> DRIVER_SENSE and
Himanshu,
> This series has couple bug fixes for the driver.
>
> First patch addresses initialization error with the newer adapter on a
> blade systems.
>
> Second patch adds protection for accidental flash corruption using SysFS
> path.
Applied to 5.4/scsi-fixes, thanks!
--
Martin K. Pe
On Fri, Oct 18, 2019 at 12:00:07AM +0530, Kashyap Desai wrote:
> > On 10/9/19 2:32 AM, Ming Lei wrote:
> > > @@ -354,7 +354,8 @@ void scsi_device_unbusy(struct scsi_device *sdev,
> > struct scsi_cmnd *cmd)
> > > if (starget->can_queue > 0)
> > > atomic_dec(&starget->targ
On 2019-10-21 23:28, Hannes Reinecke wrote:
> On 10/21/19 6:41 PM, Bart Van Assche wrote:
>> On 10/21/19 2:53 AM, Hannes Reinecke wrote:
>>> We should return the actual error code in st_scsi_execute(),
>>> avoiding the need to use DRIVER_ERROR.
>>>
>>> Signed-off-by: Hannes Reinecke
>>> ---
>>>
On 10/21/19 11:53 AM, Hannes Reinecke wrote:
Instead of returning the linux-special status (which is shifted
by 1 to the right) change the status_byte() macro to return the
correct SCSI standard status.
And audit all callers to handle this change.
Signed-off-by: Hannes Reinecke
---
drivers/sc
On 10/21/19 11:53 AM, Hannes Reinecke wrote:
Introduce scsi_build_sense() as a wrapper around
scsi_build_sense_buffer() to format the buffer and set
the correct SCSI status.
Signed-off-by: Hannes Reinecke
---
drivers/s390/scsi/zfcp_scsi.c | 5 +--
16 files changed, 60 insertio
On 10/21/19 6:44 PM, Bart Van Assche wrote:
> On 10/21/19 2:53 AM, Hannes Reinecke wrote:
>> When failing to map the user buffer we should return the actual
>> error code, avoiding the usage of DRIVER_ERROR.
>>
>> Signed-off-by: Hannes Reinecke
>> ---
>> block/scsi_ioctl.c | 7 ---
>> 1 fil
On 10/21/19 6:41 PM, Bart Van Assche wrote:
> On 10/21/19 2:53 AM, Hannes Reinecke wrote:
>> We should return the actual error code in st_scsi_execute(),
>> avoiding the need to use DRIVER_ERROR.
>>
>> Signed-off-by: Hannes Reinecke
>> ---
>> drivers/scsi/st.c | 4 ++--
>> 1 file changed, 2 ins
On 10/21/19 6:37 PM, Bart Van Assche wrote:
> On 10/21/19 2:53 AM, Hannes Reinecke wrote:
>> @@ -6021,43 +6015,28 @@ static void adv_isr_callback(ADV_DVC_VAR
>> *adv_dvc_varp, ADV_SCSI_REQ_Q *scsiqp)
>> ASC_DBG(2, "SAM_STAT_CHECK_CONDITION\n");
>> ASC_DBG_PRT_SEN
On 10/21/19 8:32 PM, Douglas Gilbert wrote:
> On 2019-10-21 5:52 a.m., Hannes Reinecke wrote:
>> Hi all,
>>
>> the 'result' field in the SCSI command is defined as having
>> 4 fields. The top byte is declared as a 'driver_byte', where the
>> driver can signal some internal status back to the midlay
On 10/22/19 1:44 AM, Finn Thain wrote:
>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>> index c40fbea06cc5..649f9610ca72 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@
On 10/22/19 1:31 AM, Finn Thain wrote:
>
> On Mon, 21 Oct 2019, Hannes Reinecke wrote:
>
>> Introduce scsi_build_sense() as a wrapper around
>> scsi_build_sense_buffer() to format the buffer and set
>> the correct SCSI status.
>>
>> Signed-off-by: Hannes Reinecke
>> ---
>> drivers/ata/libata-sc
On 10/22/19 1:17 AM, Finn Thain wrote:
> On Mon, 21 Oct 2019, Hannes Reinecke wrote:
>
>> Use standard SAM status codes and omit the explicit shift to convert
>> to linus-specific ones.
>
> "Linux-specific".
>
Indeed, it was Linus who did that :-)
Will be fixing it up.
Cheers,
Hannes
--
Dr. H
On 10/22/19 1:16 AM, Finn Thain wrote:
> On Mon, 21 Oct 2019, Hannes Reinecke wrote:
>
>> Use standard SCSI status and drop usage of the linux-specific ones.
>>
>> Signed-off-by: Hannes Reinecke
>> ---
>> drivers/scsi/wd33c93.c | 21 -
>> 1 file changed, 8 insertions(+), 13 d
On 10/22/19 12:12 AM, Finn Thain wrote:
> On Mon, 21 Oct 2019, Hannes Reinecke wrote:
>
>> To be in-line with the other set_XX_byte() functions.
>>
>> Signed-off-by: Hannes Reinecke
>> ---
>> include/scsi/scsi_cmnd.h | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/include/scsi/s
On 2019/10/21 21:06, Hannes Reinecke wrote:
> On 10/21/19 3:49 AM, zhengbin (A) wrote:
>> On 2019/10/18 21:43, Martin K. Petersen wrote:
>>> Hannes,
>>>
The one thing which I patently don't like is the ambivalence between
DRIVER_SENSE and scsi_sense_valid(). What shall we do if only _o
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index c40fbea06cc5..649f9610ca72 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -1,3 +1,4 @@
> +
> // SPDX-License-Identifier
On Mon, 21 Oct 2019, Hannes Reinecke wrote:
> Introduce scsi_build_sense() as a wrapper around
> scsi_build_sense_buffer() to format the buffer and set
> the correct SCSI status.
>
> Signed-off-by: Hannes Reinecke
> ---
> drivers/ata/libata-scsi.c | 7 ++--
> drivers/s390/scsi/zf
On Mon, 21 Oct 2019, Douglas Gilbert wrote:
>
> > As usual, comments and reviews are welcome.
>
> It is hard to make an omelette without breaking some eggs.
>
Coccinelle can minimize the breakage; particularly the
straight-forward conversion of (FOO << 1) to SAM_STAT_BAR.
--
> Doug Gilbert
On Mon, 21 Oct 2019, Hannes Reinecke wrote:
> Use standard SAM status codes and omit the explicit shift to convert
> to linus-specific ones.
"Linux-specific".
--
>
> Signed-off-by: Hannes Reinecke
> ---
> drivers/ata/libata-scsi.c | 2 +-
> drivers/infiniband/ulp/srp/ib_srp.c
On Mon, 21 Oct 2019, Hannes Reinecke wrote:
> Use standard SCSI status and drop usage of the linux-specific ones.
>
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/wd33c93.c | 21 -
> 1 file changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/scsi/wd33c
On Mon, 21 Oct 2019, Hannes Reinecke wrote:
> To be in-line with the other set_XX_byte() functions.
>
> Signed-off-by: Hannes Reinecke
> ---
> include/scsi/scsi_cmnd.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
> index 91bd
Hi Hannes,
I love your patch! Yet something to improve:
[auto build test ERROR on mkp-scsi/for-next]
[cannot apply to v5.4-rc4 next-20191021]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify t
Hi Hannes,
I love your patch! Perhaps something to improve:
[auto build test WARNING on mkp-scsi/for-next]
[also build test WARNING on v5.4-rc4 next-20191021]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' op
On 2019-10-21 5:52 a.m., Hannes Reinecke wrote:
Hi all,
the 'result' field in the SCSI command is defined as having
4 fields. The top byte is declared as a 'driver_byte', where the
driver can signal some internal status back to the midlayer.
However, there is quite a bit of overlap between the d
Hi Hannes,
I love your patch! Yet something to improve:
[auto build test ERROR on mkp-scsi/for-next]
[cannot apply to v5.4-rc4 next-20191021]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify t
On 10/21/19 2:53 AM, Hannes Reinecke wrote:
When failing to map the user buffer we should return the actual
error code, avoiding the usage of DRIVER_ERROR.
Signed-off-by: Hannes Reinecke
---
block/scsi_ioctl.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/block/s
On 10/21/19 2:53 AM, Hannes Reinecke wrote:
We should return the actual error code in st_scsi_execute(),
avoiding the need to use DRIVER_ERROR.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/st.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/st.c b/dri
On 10/21/19 2:53 AM, Hannes Reinecke wrote:
@@ -6021,43 +6015,28 @@ static void adv_isr_callback(ADV_DVC_VAR *adv_dvc_varp,
ADV_SCSI_REQ_Q *scsiqp)
ASC_DBG(2, "SAM_STAT_CHECK_CONDITION\n");
ASC_DBG_PRT_SENSE(2, scp->sense_buffer,
On 10/21/19 3:22 PM, Douglas Gilbert wrote:
> On 2019-10-18 6:05 a.m., Hannes Reinecke wrote:
[ .. ]
>> One thing to keep in mind here is that 'set_bit()' is not atomic; it
>> needs to be followed by a memory barrier or being replaced by
>> test_and_set_bit() if possible.
>> Please audit the code i
On 2019-10-18 6:05 a.m., Hannes Reinecke wrote:
On 10/8/19 9:50 AM, Douglas Gilbert wrote:
Introduce bitops in sg_device to replace an atomic, a bool and a
char. That char (sgdebug) had been reduced to only two states.
Add some associated macros to make the code a little clearer.
Signed-off-by:
On 10/21/19 3:49 AM, zhengbin (A) wrote:
>
> On 2019/10/18 21:43, Martin K. Petersen wrote:
>> Hannes,
>>
>>> The one thing which I patently don't like is the ambivalence between
>>> DRIVER_SENSE and scsi_sense_valid(). What shall we do if only _one_
>>> of them is set? IE what would be the corr
Hi zhengbin,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on mkp-scsi/for-next]
[cannot apply to v5.4-rc4 next-20191018]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to s
On 18/10/2019 15:43, Martin K. Petersen wrote:
[...]
> Johannes: Whatever happened to your efforts at cleaning all this up? Do
> you have a patch series or a working tree we could use as starting
> point?
I'll have to look. I think it's still floating around in some git tree.
Let me search for it
On 2019-10-18 03:01, zhengbin wrote:
> @@ -1648,16 +1651,20 @@ static int sd_sync_cache(struct scsi_disk *sdkp,
> struct scsi_sense_hdr *sshdr)
> if (res) {
> sd_print_result(sdkp, "Synchronize Cache(10) failed", res);
>
> - if (driver_byte(res) == DRIVER_SENSE)
>
On 2019/10/18 21:43, Martin K. Petersen wrote:
> Hannes,
>
>> The one thing which I patently don't like is the ambivalence between
>> DRIVER_SENSE and scsi_sense_valid(). What shall we do if only _one_
>> of them is set? IE what would be the correct way of action if
>> DRIVER_SENSE is not set,
On 10/18/19 11:45 PM, James Smart wrote:
On 10/18/2019 12:50 AM, Hannes Reinecke wrote:
Hi James,
trying to figure this annoying lpfc_set_rrq_active() bug
I've found the nodelist pointer handling in the lpfc io buffers
a bit strange; there's a 'ndlp' pointer, but for scsi the nodelist
is primar
On 10/18/19 11:44 PM, Martin K. Petersen wrote:
Hannes,
If a target only supports implicit ALUA sending a SET TARGET PORT
GROUPS command is not only pointless, but might actually cause issues.
We already have a conditional in alua_stpg():
if (!(pg->tpgs & TPGS_MODE_EXPLICIT)) {
Balsundar,
> Balsundar P (7):
> scsi: aacraid: Fix illegal data read or write beyond last LBA
> scsi: aacraid: Fixed failure to check IO response and report IO error
> scsi: aacraid: Fixed basecode assert when IOP reset is sent by driver
> scsi: aacraid: setting different timeout for src
On Fri, 18 Oct 2019, Martin K. Petersen wrote:
>
> (Sorry, zhengbin, you opened a can of worms. This is some of our oldest
> and most arcane code in SCSI)
>
A call to set_host_byte(cmd, x) or set_msg_byte(cmd, x) when x & 0x80 is
set clobbers the most significant bytes in cmd->result.
Avoid t
Avri,
> The scsi async probe process is calling blk_pm_runtime_init for each
> lun, and then those request queues are monitored by the block layer pm
> engine (blk-pm.c). This is however, not the case for scsi-passthrough
> queues, created by bsg_setup_queue().
>
> So the ufs-bsg driver might s
Hannes,
> If a target only supports implicit ALUA sending a SET TARGET PORT
> GROUPS command is not only pointless, but might actually cause issues.
We already have a conditional in alua_stpg():
if (!(pg->tpgs & TPGS_MODE_EXPLICIT)) {
/* Only implicit ALUA supported, re
On 10/18/2019 12:50 AM, Hannes Reinecke wrote:
Hi James,
trying to figure this annoying lpfc_set_rrq_active() bug
I've found the nodelist pointer handling in the lpfc io buffers
a bit strange; there's a 'ndlp' pointer, but for scsi the nodelist
is primarily accessed via the 'rdata' pointer (alth
Hannes,
> DRIVER_ERROR is a a driver byte setting, not a host byte. The qla2xxx
> driver should rather return DID_ERROR here to be in line with the
> other drivers.
Applied to 5.4/scsi-fixes, thanks!
--
Martin K. Petersen Oracle Linux Engineering
James,
> I assume that 5.4/scsi-fixes will get merged into 5.4 pre-release,
Yes.
> and that the stable tree will rebase to pick it up ?
stable/master is tracking Linus until final release.
If you want the stats issue fixed in 5.3, it's best to wait for Hannes'
commit to be merged by Linus. Y
On 10/17/2019 7:01 PM, Martin K. Petersen wrote:
Hannes,
The BUILD_NVME define never got defined anywhere, causing NVMe
commands to be treated as SCSI commands when freeing the buffers.
This was causing a stuck discovery and a horrible crash in
lpfc_set_rrq_active() later on.
Applied to 5.4/sc
Hannes, this is already in
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/log/?h=5.4/scsi-postmerge
from
https://lore.kernel.org/linux-block/20190807144948.28265-1-ma...@linux.ibm.com/T/
and Martin just sent a pull request to Linus
https://lore.kernel.org/linux-scsi/yq1pniui429..
On 10/18/19 3:43 PM, Martin K. Petersen wrote:
>
> Hannes,
>
>> The one thing which I patently don't like is the ambivalence between
>> DRIVER_SENSE and scsi_sense_valid(). What shall we do if only _one_
>> of them is set? IE what would be the correct way of action if
>> DRIVER_SENSE is not set
Hannes,
> The one thing which I patently don't like is the ambivalence between
> DRIVER_SENSE and scsi_sense_valid(). What shall we do if only _one_
> of them is set? IE what would be the correct way of action if
> DRIVER_SENSE is not set, but we have a valid sense code? Or the other
> way ar
On 2019/10/18 17:17, zhengbin wrote:
> v1->v2: modify the comments suggested by Bart
> v2->v3: fix bug in sr_do_ioctl
> v3->v4: let "fix bug in sr_do_ioctl" be a separate patch
> v4->v5: fix uninit-value access bug in callers, not in __scsi_execute
An explanation text of the series would be great.
On 10/8/19 9:50 AM, Douglas Gilbert wrote:
> Replace sg_fill_request_table() with sg_fill_request_element().
> Reduce the size of the sg_rq_end_io() function by breaking out
> some sense buffer checks into sg_check_sense(). Reduce the
> size of the sg_start_req() function with sg_set_map_data()
> h
On 10/8/19 9:50 AM, Douglas Gilbert wrote:
> Replace sg_get_rq_mark() with sg_find_srp_by_id() and
> sg_get_ready_srp(). Add sg_chk_mmap() to check flags and
> reserve buffer available for mmap() based requests. Add
> sg_copy_sense() and sg_rec_v3_state() which is just
> refactoring. Add sg_calc_rq
On 10/8/19 9:50 AM, Douglas Gilbert wrote:
> The introduced request state machine is not wired in so that
> the size of one of the following patches is reduced. Bit
> operation defines for the request and file descriptor level
> are also introduced. Minor rework og sg_rd_append() function.
>
> Sig
On 10/8/19 9:50 AM, Douglas Gilbert wrote:
> Rename sg_build_indirect() to sg_mk_sgat() and sg_remove_scat()
> to sg_remove_sgat(). Re-implement those functions. Add
> sg_calc_sgat_param() to calculate various scatter gather
> list parameters. Some other minor clean-ups.
>
On 10/8/19 9:50 AM, Douglas Gilbert wrote:
> Replace the sg_allow_access() function with sg_fetch_cmnd()
> which does a little more. Change sg_finish_scsi_blk_rq() from an
> int to a void returning function. Rename sg_remove_request()
> to sg_deact_request(). Other changes, mainly cosmetic.
>
> Si
On 10/8/19 9:50 AM, Douglas Gilbert wrote:
> Simple rework of the sg_mmap() function.
>
> Signed-off-by: Douglas Gilbert
> ---
> drivers/scsi/sg.c | 25 +++--
> 1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
> index b
On 10/8/19 9:50 AM, Douglas Gilbert wrote:
> Simple refactoring of the sg_vma_fault() function.
>
> Signed-off-by: Douglas Gilbert
> ---
> drivers/scsi/sg.c | 33 +++--
> 1 file changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/scsi/sg.c b/drivers/s
On 10/8/19 9:50 AM, Douglas Gilbert wrote:
> As the number of arguments to sg_common_write() starts to grow
> (more in later patches) add a structure to hold most of these
> arguments.
>
> Signed-off-by: Douglas Gilbert
> ---
> drivers/scsi/sg.c | 47 -
On 10/8/19 9:50 AM, Douglas Gilbert wrote:
> As sg_read() is getting quite long, split out the v1 and v2
> processing into sg_rd_v1v2(). Rename sg_new_read() to
> sg_v3_receive() as the v3 interface is now older than the v4
> interface which is being added in a later patch.
>
> Signed-off-by: Doug
On 10/8/19 9:50 AM, Douglas Gilbert wrote:
> Shorten sg_ioctl() by adding some helper functions. sg_ioctl()
> is the main entry point for ioctls used on this driver's
> devices.
>
> Signed-off-by: Douglas Gilbert
> ---
> drivers/scsi/sg.c | 325 --
> 1
On 10/8/19 9:50 AM, Douglas Gilbert wrote:
> A reviewer suggested that the extra overhead associated with a
> rw lock compared to a spinlock was not worth it for short,
> oft-used critcal sections.
>
> So the rwlock on the request list/array is changed to a spinlock.
> The head of that list is in
On 10/8/19 9:50 AM, Douglas Gilbert wrote:
> Introduce bitops in sg_device to replace an atomic, a bool and a
> char. That char (sgdebug) had been reduced to only two states.
> Add some associated macros to make the code a little clearer.
>
> Signed-off-by: Douglas Gilbert
> ---
> drivers/scsi/s
On 10/8/19 9:50 AM, Douglas Gilbert wrote:
> Remove use of typedef sg_io_hdr_t and replace with struct
> sg_io_hdr. Change some names on driver wide structure fields
> and comment them.
>
> Signed-off-by: Douglas Gilbert
> ---
> drivers/scsi/sg.c | 234 +--
zhengbin,
> Like other callers of scsi_execute(send_trespass_cmd, hp_sw_tur...),
> we need to check whether sshdr is valid.
Applied to 5.4/scsi-fixes, thanks!
--
Martin K. Petersen Oracle Linux Engineering
On 10/18/19 10:24 AM, zhengbin wrote:
> v1->v2: modify the comments suggested by Bart
> v2->v3: fix bug in sr_do_ioctl
> v3->v4: let "fix bug in sr_do_ioctl" be a separate patch
> v4->v5: fix uninit-value access bug in callers, not in __scsi_execute
>
> zhengbin (13):
> scsi: core: need to check
zhengbin,
> We can init sshdr in sr_get_events, but there have many callers of
> scsi_execute, scsi_execute_req, we have to troubleshoot all callers,
> the simpler way is init sshdr in __scsi_execute.
There aren't that many callers. I'd prefer to make sure that everybody
is handling DRIVER_SENS
Acked-by: Balsundar P < balsunda...@microchip.com>
-Original Message-
From: kbuild test robot
Sent: Wednesday, October 16, 2019 00:28
To: balsunda...@microsemi.com
Cc: kbuild-...@lists.01.org; linux-scsi@vger.kernel.org;
j...@linux.vnet.ibm.com; aacr...@microsemi.com
Subject: [RFC PATCH
On 2019/10/18 10:40, Martin K. Petersen wrote:
> zhengbin,
>
>> We can init sshdr in sr_get_events, but there have many callers of
>> scsi_execute, scsi_execute_req, we have to troubleshoot all callers,
>> the simpler way is init sshdr in __scsi_execute.
> There aren't that many callers. I'd pref
zhengbin,
>> Like other callers of scsi_execute(send_trespass_cmd, hp_sw_tur...),
>> we need to check whether sshdr is valid.
>
> Applied to 5.4/scsi-fixes, thanks!
Actually, after looking at this again, the function is making the
assumption that if driver_byte(result) != 0, then the sense is
p
zhengbin,
> I modify these in a patch? or every .c a patch, use a patchset?
A patchset consisting of one patch per file, please.
Thank you!
--
Martin K. Petersen Oracle Linux Engineering
Hannes,
> The BUILD_NVME define never got defined anywhere, causing NVMe
> commands to be treated as SCSI commands when freeing the buffers.
> This was causing a stuck discovery and a horrible crash in
> lpfc_set_rrq_active() later on.
Applied to 5.4/scsi-fixes, thanks!
--
Martin K. Petersen
>> We have a test case like block/001 in blktests, which will create a
>> scsi device by loading scsi_debug module and then try to delete the
>> device by sysfs interface. At the same time, it may remove the
>> scsi_debug module.
Applied to 5.4/scsi-fixes, thanks!
> Please consider to contribut
Don,
> - correct returning from reset before outstanding
> commands are completed for the device.
Applied to 5.4/scsi-fixes, thanks!
--
Martin K. Petersen Oracle Linux Engineering
> On 10/9/19 2:32 AM, Ming Lei wrote:
> > @@ -354,7 +354,8 @@ void scsi_device_unbusy(struct scsi_device *sdev,
> struct scsi_cmnd *cmd)
> > if (starget->can_queue > 0)
> > atomic_dec(&starget->target_busy);
> >
> > - atomic_dec(&sdev->device_busy);
> > + if (!blk_queue_nonrot(s
On 10/17/2019 8:00 AM, Hannes Reinecke wrote:
The BUILD_NVME define never got defined anywhere, causing
NVMe commands to be treated as SCSI commands when freeing
the buffers.
This was causing a stuck discovery and a horrible crash
in lpfc_set_rrq_active() later on.
Fixes: c00f62e6c546 ("scsi: lp
On 2019/10/17 10:45, Bart Van Assche wrote:
> On 2019-10-11 20:25, zhengbin wrote:
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index 5447738..d5e29c5 100644
>> --- a/drivers/scsi/scsi_lib.c
>> +++ b/drivers/scsi/scsi_lib.c
>> @@ -255,6 +255,13 @@ int __scsi_execute(struct
On 2019-10-11 20:25, zhengbin wrote:
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 5447738..d5e29c5 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -255,6 +255,13 @@ int __scsi_execute(struct scsi_device *sdev, const
> unsigned char *cmd,
>
On 2019-10-15 06:05, Yufen Yu wrote:
> We have a test case like block/001 in blktests, which will
> create a scsi device by loading scsi_debug module and then
> try to delete the device by sysfs interface. At the same time,
> it may remove the scsi_debug module.
Please consider to contribute the t
On 2019/10/17 8:05, Finn Thain wrote:
> On Sat, 12 Oct 2019, zhengbin wrote:
>
>> kmsan report a warning in 5.1-rc4:
>>
>> BUG: KMSAN: uninit-value in sr_get_events drivers/scsi/sr.c:207 [inline]
>> BUG: KMSAN: uninit-value in sr_check_events+0x2cf/0x1090
>> drivers/scsi/sr.c:243
>> CPU: 1 PID:
On Sat, 12 Oct 2019, zhengbin wrote:
> kmsan report a warning in 5.1-rc4:
>
> BUG: KMSAN: uninit-value in sr_get_events drivers/scsi/sr.c:207 [inline]
> BUG: KMSAN: uninit-value in sr_check_events+0x2cf/0x1090 drivers/scsi/sr.c:243
> CPU: 1 PID: 13858 Comm: syz-executor.0 Tainted: GB
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on scsi/for-next]
[cannot apply to v5.4-rc3 next-20191014]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify
On 2019/10/12 10:06, James Bottomley wrote:
> On Sat, 2019-10-12 at 10:03 +0800, zhengbin (A) wrote:
>> On 2019/10/12 9:58, James Bottomley wrote:
>>> On Sat, 2019-10-12 at 09:26 +0800, zhengbin wrote:
BTW: we can't just init sshdr->response_code, sr_do_ioctl use
sshdr->sense_key
>>> Th
On Sat, 2019-10-12 at 10:03 +0800, zhengbin (A) wrote:
> On 2019/10/12 9:58, James Bottomley wrote:
> > On Sat, 2019-10-12 at 09:26 +0800, zhengbin wrote:
> > > BTW: we can't just init sshdr->response_code, sr_do_ioctl use
> > > sshdr->sense_key
> >
> > That's an actual bug, isn't it?
>
> If we i
On 2019/10/12 9:58, James Bottomley wrote:
> On Sat, 2019-10-12 at 09:26 +0800, zhengbin wrote:
>> BTW: we can't just init sshdr->response_code, sr_do_ioctl use
>> sshdr->sense_key
> That's an actual bug, isn't it?
If we init sshdr in __scsi_execute, this will be ok
>
> James
>
>
> .
>
On Sat, 2019-10-12 at 09:26 +0800, zhengbin wrote:
> BTW: we can't just init sshdr->response_code, sr_do_ioctl use
> sshdr->sense_key
That's an actual bug, isn't it?
James
On 10/10/19 5:05 AM, zhengbin wrote:
+ /*
+* need to initial sshdr to avoid uninit-value access
+*/
+ if (sshdr)
+ memset(sshdr, 0, sizeof(struct scsi_sense_hdr));
+
I think the above comment is slightly confusing because it is correct
for some callers
On 10/10/19 8:07 PM, zhengbin (A) wrote:
Besides, scsi_sense_hdr is just 8 bytes, memset it to 0 will not affect
performance
That's true ...
Bart.
On 2019/10/11 1:03, Bart Van Assche wrote:
> On 10/10/19 5:05 AM, zhengbin wrote:
>> kmsan report a warning in 5.1-rc4:
>>
>> BUG: KMSAN: uninit-value in sr_get_events drivers/scsi/sr.c:207 [inline]
>> BUG: KMSAN: uninit-value in sr_check_events+0x2cf/0x1090
>> drivers/scsi/sr.c:243
>> CPU: 1 PI
On 10/10/2019 1:59 AM, Zhangguanghui wrote:
Hi everyone
Please refer to the latest patch.
There is a race deadlock in the function lpfc_abort_handler
potential deadlocks arising from lock ordering problems.
It’s the correct order
spin_unlock(&lpfc_cmd->buf_lock)
spin_unlock_irqrestore(&phba
On 10/10/19 5:05 AM, zhengbin wrote:
kmsan report a warning in 5.1-rc4:
BUG: KMSAN: uninit-value in sr_get_events drivers/scsi/sr.c:207 [inline]
BUG: KMSAN: uninit-value in sr_check_events+0x2cf/0x1090 drivers/scsi/sr.c:243
CPU: 1 PID: 13858 Comm: syz-executor.0 Tainted: GB 5.1.0
Bart,
> Clearing ch->device in ch_release() is wrong because that pointer must
> remain valid until ch_remove() is called. This patch fixes the
> following crash the second time a ch device is opened:
Applied to 5.4/scsi-fixes, thank you!
--
Martin K. Petersen Oracle Linux Engineering
Chandrakanth,
> Currently, MSIx vectors name appears in /proc/interrupts is "megasas"
> which is same for all the vectors. This patch provides the unique
> name to all megaraid_sas controllers and its associated MSIx interrupts.
>
> Suggested-by: Konstantin Shalygin
> Signed-off-by: Sumit Saxen
Don,
> These patches are based on Linus's tree
Applied to 5.5/scsi-queue. There was some fuzz but I think I figured it
out.
--
Martin K. Petersen Oracle Linux Engineering
1 - 100 of 46964 matches
Mail list logo
