Re: [PATCH] qlogicpti: fixup qlogicpti_reset() definition

Hannes, > A merge error crept in when formatting commit af167bc ("scsi: > qlogicpti: move bus reset to host reset") Applied to 4.14/scsi-queue. Thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: qedi: off by one in qedi_get_cmd_from_tid()

Dan, > The > here should be >= or we end up reading one element beyond the > end of the qedi->itt_map[] array. The qedi->itt_map[] array is > allocated in qedi_alloc_itt(). Applied to 4.13/scsi-fixes. Thank you! -- Martin K. Petersen Oracle Linux Engineering

[PATCH] storvsc: fix memory leak on ring buffer busy

From: Long Li When storvsc is sending I/O to Hyper-v, it may allocate a bigger buffer descriptor for large data payload that can't fit into a pre-allocated buffer descriptor. This bigger buffer is freed on return path. If I/O request to Hyper-v fails due to ring buffer

Re: [PATCH v3 1/3] rcu: Introduce rcu_swap_protected()

On Mon, Aug 28, 2017 at 09:39:18PM +, Bart Van Assche wrote: > On Mon, 2017-08-28 at 14:26 -0700, Paul E. McKenney wrote: > > On Mon, Aug 28, 2017 at 01:46:13PM -0700, Bart Van Assche wrote: > > > A common pattern in RCU code is to assign a new value to an RCU > > > pointer after having read

Re: [PATCH v2 17/30] scsi: Define usercopy region in scsi_sense_cache slab cache

On Mon, Aug 28, 2017 at 2:42 PM, Bart Van Assche wrote: > On Mon, 2017-08-28 at 14:34 -0700, Kees Cook wrote: >> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c >> index f6097b89d5d3..f1c6bd56dd5b 100644 >> --- a/drivers/scsi/scsi_lib.c >> +++

Re: [PATCH v2 17/30] scsi: Define usercopy region in scsi_sense_cache slab cache

On Mon, 2017-08-28 at 14:34 -0700, Kees Cook wrote: > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c > index f6097b89d5d3..f1c6bd56dd5b 100644 > --- a/drivers/scsi/scsi_lib.c > +++ b/drivers/scsi/scsi_lib.c > @@ -77,14 +77,15 @@ int scsi_init_sense_cache(struct Scsi_Host *shost) >

Re: [PATCH v3 1/3] rcu: Introduce rcu_swap_protected()

On Mon, 2017-08-28 at 14:26 -0700, Paul E. McKenney wrote: > On Mon, Aug 28, 2017 at 01:46:13PM -0700, Bart Van Assche wrote: > > A common pattern in RCU code is to assign a new value to an RCU > > pointer after having read and stored the old value. Introduce a > > macro for this pattern. > > > >

[PATCH v2 17/30] scsi: Define usercopy region in scsi_sense_cache slab cache

From: David Windsor SCSI sense buffers, stored in struct scsi_cmnd.sense and therefore contained in the scsi_sense_cache slab cache, need to be copied to/from userspace. cache object allocation: drivers/scsi/scsi_lib.c: scsi_select_sense_cache(...):

Re: [PATCH v3 1/3] rcu: Introduce rcu_swap_protected()

On Mon, Aug 28, 2017 at 01:46:13PM -0700, Bart Van Assche wrote: > A common pattern in RCU code is to assign a new value to an RCU > pointer after having read and stored the old value. Introduce a > macro for this pattern. > > Signed-off-by: Bart Van Assche > Cc: Paul E.

Re: [PATCH v3 0/3] Rework handling of scsi_device.vpd_pg8[03]

On Mon, 2017-08-28 at 13:45 -0700, Bart Van Assche wrote: > The conclusion of a recent discussion about the handling of SCSI device VPD > [ ... ] Please ignore this series too. I think I finally found and fixed the bug in the script I use to post patches ... Bart.

[PATCH v3 3/3] Rework handling of scsi_device.vpd_pg8[03]

Introduce struct scsi_vpd for the VPD page length, data and the RCU head that will be used to free the VPD data. Use kfree_rcu() instead of kfree() to free VPD data. Move the VPD buffer pointer check inside the RCU read lock in the sysfs code. Only annotate pointers that are shared across threads

[PATCH v3 2/3] Rework the code for caching Vital Product Data (VPD)

Introduce the scsi_get_vpd_buf() and scsi_update_vpd_page() functions. The only functional change in this patch is that if updating page 0x80 fails that it is attempted to update page 0x83. Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Hannes

[PATCH v3 2/3] Rework the code for caching Vital Product Data (VPD)

Introduce the scsi_get_vpd_buf() and scsi_update_vpd_page() functions. The only functional change in this patch is that if updating page 0x80 fails that it is attempted to update page 0x83. Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Hannes

[PATCH v3 0/3] Rework handling of scsi_device.vpd_pg8[03]

Hello Martin, The conclusion of a recent discussion about the handling of SCSI device VPD data is that the code should be reworked such that that data is freed through kfree_rcu() instead of kfree(). The three patches in this series realize this and also simplify the VPD code. Please consider

[PATCH v3 1/3] rcu: Introduce rcu_swap_protected()

A common pattern in RCU code is to assign a new value to an RCU pointer after having read and stored the old value. Introduce a macro for this pattern. Signed-off-by: Bart Van Assche Cc: Paul E. McKenney Cc: Ingo Molnar Cc:

[PATCH v3 3/3] Rework handling of scsi_device.vpd_pg8[03]

Introduce struct scsi_vpd for the VPD page length, data and the RCU head that will be used to free the VPD data. Use kfree_rcu() instead of kfree() to free VPD data. Move the VPD buffer pointer check inside the RCU read lock in the sysfs code. Only annotate pointers that are shared across threads

Re: [PATCH v3 0/3] Rework handling of scsi_device.vpd_pg8[03]

On Mon, 2017-08-28 at 13:44 -0700, Bart Van Assche wrote: > The conclusion of a recent discussion about the handling of SCSI device VPD > [ ... ] Please ignore this patch series too - same problem as last time. Bart.

[PATCH v3 0/3] Rework handling of scsi_device.vpd_pg8[03]

Hello Martin, The conclusion of a recent discussion about the handling of SCSI device VPD data is that the code should be reworked such that that data is freed through kfree_rcu() instead of kfree(). The three patches in this series realize this and also simplify the VPD code. Please consider

[PATCH v3 1/3] rcu: Introduce rcu_swap_protected()

A common pattern in RCU code is to assign a new value to an RCU pointer after having read and stored the old value. Introduce a macro for this pattern. Signed-off-by: Bart Van Assche Cc: Paul E. McKenney Cc: Ingo Molnar Cc:

[PATCH v3 2/3] Rework the code for caching Vital Product Data (VPD)

Introduce the scsi_get_vpd_buf() and scsi_update_vpd_page() functions. The only functional change in this patch is that if updating page 0x80 fails that it is attempted to update page 0x83. Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Hannes

[PATCH v3 3/3] Rework handling of scsi_device.vpd_pg8[03]

Introduce struct scsi_vpd for the VPD page length, data and the RCU head that will be used to free the VPD data. Use kfree_rcu() instead of kfree() to free VPD data. Move the VPD buffer pointer check inside the RCU read lock in the sysfs code. Only annotate pointers that are shared across threads

[PATCH v3 2/3] Rework the code for caching Vital Product Data (VPD)

Introduce the scsi_get_vpd_buf() and scsi_update_vpd_page() functions. The only functional change in this patch is that if updating page 0x80 fails that it is attempted to update page 0x83. Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Hannes

[PATCH v3 3/3] Rework handling of scsi_device.vpd_pg8[03]

Introduce struct scsi_vpd for the VPD page length, data and the RCU head that will be used to free the VPD data. Use kfree_rcu() instead of kfree() to free VPD data. Move the VPD buffer pointer check inside the RCU read lock in the sysfs code. Only annotate pointers that are shared across threads

[PATCH v3 1/3] rcu: Introduce rcu_swap_protected()

A common pattern in RCU code is to assign a new value to an RCU pointer after having read and stored the old value. Introduce a macro for this pattern. Signed-off-by: Bart Van Assche Cc: Paul E. McKenney Cc: Ingo Molnar Cc:

[PATCH v3 1/3] rcu: Introduce rcu_swap_protected()

A common pattern in RCU code is to assign a new value to an RCU pointer after having read and stored the old value. Introduce a macro for this pattern. Signed-off-by: Bart Van Assche Cc: Paul E. McKenney Cc: Ingo Molnar Cc:

[PATCH v3 0/3] Rework handling of scsi_device.vpd_pg8[03]

Hello Martin, The conclusion of a recent discussion about the handling of SCSI device VPD data is that the code should be reworked such that that data is freed through kfree_rcu() instead of kfree(). The three patches in this series realize this and also simplify the VPD code. Please consider

[PATCH v3 0/3] Rework handling of scsi_device.vpd_pg8[03]

Hello Martin, The conclusion of a recent discussion about the handling of SCSI device VPD data is that the code should be reworked such that that data is freed through kfree_rcu() instead of kfree(). The three patches in this series realize this and also simplify the VPD code. Please consider

[PATCH v3 3/3] Rework handling of scsi_device.vpd_pg8[03]

Introduce struct scsi_vpd for the VPD page length, data and the RCU head that will be used to free the VPD data. Use kfree_rcu() instead of kfree() to free VPD data. Move the VPD buffer pointer check inside the RCU read lock in the sysfs code. Only annotate pointers that are shared across threads

[PATCH v3 1/3] rcu: Introduce rcu_swap_protected()

A common pattern in RCU code is to assign a new value to an RCU pointer after having read and stored the old value. Introduce a macro for this pattern. Signed-off-by: Bart Van Assche Cc: Paul E. McKenney Cc: Ingo Molnar Cc:

[PATCH v3 2/3] Rework the code for caching Vital Product Data (VPD)

Introduce the scsi_get_vpd_buf() and scsi_update_vpd_page() functions. The only functional change in this patch is that if updating page 0x80 fails that it is attempted to update page 0x83. Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Hannes

[PATCH v3 0/3] Rework handling of scsi_device.vpd_pg8[03]

Hello Martin, The conclusion of a recent discussion about the handling of SCSI device VPD data is that the code should be reworked such that that data is freed through kfree_rcu() instead of kfree(). The three patches in this series realize this and also simplify the VPD code. Please consider

Re: [PATCH v3 0/3] Rework handling of scsi_device.vpd_pg8[03]

On Mon, 2017-08-28 at 13:41 -0700, Bart Van Assche wrote: > The conclusion of a recent discussion about the handling of SCSI device VPD > [ ... ] Please ignore this patch series - my working directory was not clean when I ran the command to post these patches. Bart.

[PATCH v3 3/3] scsi_transport_sas: Fix error handling in sas_smp_request()

sas_function_template.smp_handler implementations either return 0 or a Unix error code. Convert that error code into a SCSI result. This patch is what I came up with after having analyzed the following sparse warnings: drivers/scsi/scsi_transport_sas.c:187:21: warning: incorrect type in

[PATCH v3 2/3] Rework handling of scsi_device.vpd_pg8[03]

Introduce struct scsi_vpd for the VPD page length, data and the RCU head that will be used to free the VPD data. Use kfree_rcu() instead of kfree() to free VPD data. Move the VPD buffer pointer check inside the RCU read lock in the sysfs code. Only annotate pointers that are shared across threads

[PATCH v3 0/3] Rework handling of scsi_device.vpd_pg8[03]

Hello Martin, The conclusion of a recent discussion about the handling of SCSI device VPD data is that the code should be reworked such that that data is freed through kfree_rcu() instead of kfree(). The three patches in this series realize this and also simplify the VPD code. Please consider

[PATCH v3 1/3] Rework the code for caching Vital Product Data (VPD)

Introduce the scsi_get_vpd_buf() and scsi_update_vpd_page() functions. The only functional change in this patch is that if updating page 0x80 fails that it is attempted to update page 0x83. Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Hannes

[PATCH v3 3/3] scsi_transport_sas: Fix error handling in sas_smp_request()

sas_function_template.smp_handler implementations either return 0 or a Unix error code. Convert that error code into a SCSI result. This patch is what I came up with after having analyzed the following sparse warnings: drivers/scsi/scsi_transport_sas.c:187:21: warning: incorrect type in

[PATCH v3 1/3] Rework the code for caching Vital Product Data (VPD)

Introduce the scsi_get_vpd_buf() and scsi_update_vpd_page() functions. The only functional change in this patch is that if updating page 0x80 fails that it is attempted to update page 0x83. Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Hannes

[PATCH v3 2/3] Rework handling of scsi_device.vpd_pg8[03]

Introduce struct scsi_vpd for the VPD page length, data and the RCU head that will be used to free the VPD data. Use kfree_rcu() instead of kfree() to free VPD data. Move the VPD buffer pointer check inside the RCU read lock in the sysfs code. Only annotate pointers that are shared across threads

[PATCH v3 0/3] Rework handling of scsi_device.vpd_pg8[03]

Hello Martin, The conclusion of a recent discussion about the handling of SCSI device VPD data is that the code should be reworked such that that data is freed through kfree_rcu() instead of kfree(). The three patches in this series realize this and also simplify the VPD code. Please consider

Re: linux-next: manual merge of the scsi tree with the staging tree

On Mon, Aug 28, 2017 at 06:51:59PM +0100, James Bottomley wrote: > On Mon, 2017-08-28 at 18:44 +0200, g...@kroah.com wrote: > > On Mon, Aug 28, 2017 at 04:36:06PM +, Bart Van Assche wrote: > > > > > > On Mon, 2017-08-28 at 18:05 +0200, g...@kroah.com wrote: > > > > > > > > On Mon, Aug 28,

RE: [PATCH 2/4] hpsa: remove the smp_handler stub

From: linux-scsi-ow...@vger.kernel.org [linux-scsi-ow...@vger.kernel.org] on behalf of Christoph Hellwig [h...@lst.de] Sent: Friday, August 25, 2017 8:37 AM To: Chaitra Basappa; linux-scsi@vger.kernel.org Cc: Bart Van Assche Subject: [PATCH 2/4] hpsa:

Re: linux-next: manual merge of the scsi tree with the staging tree

On Mon, 2017-08-28 at 18:44 +0200, g...@kroah.com wrote: > On Mon, Aug 28, 2017 at 04:36:06PM +, Bart Van Assche wrote: > > > > On Mon, 2017-08-28 at 18:05 +0200, g...@kroah.com wrote: > > > > > > On Mon, Aug 28, 2017 at 03:41:28PM +, Bart Van Assche wrote: > > > > > > > > * Most SCSI

ALPSS: reminder and submission deadline

Just one more month to go until the Alpine Linux Persistence and Storage Summit (ALPSS) will be held from September 27-29 at the Lizumerhuette in Austria! If you want to submit a 30-minute talk please do so until Sep 1st, as we plan to finalize our schedule. BOFs and team meetings will be

Re: [PATCH] scsi: ufs: Make use of UFS_BIT macro wherever possible

On Mon, 2017-08-28 at 17:49 +0530, Alim Akhtar wrote: > This entire file uses UFS_BIT macro for bits definition, expect for few > places. This patch convert those defines to use UFS_BIT macro to be aligned > with reset of the file. This is the definition of the UFS_BIT() macro I found in

[PATCH] lpfc: Don't return internal MBXERR_ERROR code from probe function

Internal error codes happen to be positive, thus the PCI driver core won't treat them as failure, but we do. This would cause a crash later on as lpfc_pci_remove_one() is called (e.g. as shutdown function). Fixes: 6d368e532168 ("[SCSI] lpfc 8.3.24: Add resource extent support") Signed-off-by:

[PATCH] scsi: ufs: Make use of UFS_BIT macro wherever possible

This entire file uses UFS_BIT macro for bits definition, expect for few places. This patch convert those defines to use UFS_BIT macro to be aligned with reset of the file. Signed-off-by: Alim Akhtar --- drivers/scsi/ufs/ufshci.h | 6 +++--- 1 file changed, 3

Re: [PATCH v3 15/20] lpfc: Fix nvme target failure after 2nd adapter reset

Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB

Re: [PATCH v3 13/20] lpfc: Fix MRQ > 1 context list handling

Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB

Re: [PATCH v3 11/20] lpfc: Correct issues with FAWWN and FDISCs

Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB

Re: [PATCH v3 12/20] lpfc: Limit amount of work processed in IRQ

Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB

Re: [PATCH v3 04/20] lpfc: Fix oops when NVME Target is discovered in a nonNVME environment

Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB

[PATCH] qlogicpti: fixup qlogicpti_reset() definition

A merge error crept in when formatting commit af167bc ("scsi: qlogicpti: move bus reset to host reset") Fixes: af167bc ("scsi: qlogicpti: move bus reset to host reset") Signed-off-by: Hannes Reinecke --- drivers/scsi/qlogicpti.c | 3 ++- 1 file changed, 2 insertions(+), 1

Re: [PATCH 2/2] Rework handling of scsi_device.vpd_pg8[03]

This looks generally good. But I wonder if there is a way to factor the assining/clearing sequence into little helpers instead of duplicating it?

Re: [PATCH 1/2] Introduce scsi_get_vpd_buf()

On Fri, Aug 25, 2017 at 01:36:00PM -0700, Bart Van Assche wrote: > > if (pg80_supported) { > -retry_pg80: > - vpd_buf = kmalloc(vpd_len, GFP_KERNEL); > - if (!vpd_buf) > - return; > - > - result = scsi_vpd_inquiry(sdev, vpd_buf, 0x80,

RE: [PATCH 2/2] Rework handling of scsi_device.vpd_pg8[03]

Hi Bart, Comments inline below about the show_vpd_##_page macro. > -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@wdc.com] > Sent: Saturday, August 26, 2017 6:36 AM > To: Martin K . Petersen ; James E . J . > Bottomley

RE: [PATCH 1/2] Introduce scsi_get_vpd_buf()

Reviewed-by: Shane Seymour > -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@wdc.com] > Sent: Saturday, August 26, 2017 6:36 AM > To: Martin K . Petersen ; James E . J . > Bottomley > Cc: