Re: [PATCH] scsi: lpfc: fix linking against modular NVMe support

Note: the patch I referenced (http://www.spinics.net/lists/linux-scsi/msg106102.html) replaced the one I think you referenced below (http://www.spinics.net/lists/linux-scsi/msg106024.html) -- james On 3/21/2017 7:23 PM, James Smart wrote: Arnd, All of the build issues, including building

Re: [PATCH] scsi: lpfc: fix linking against modular NVMe support

Arnd, All of the build issues, including building as modules, should have been resolved by the following patch: http://www.spinics.net/lists/linux-scsi/msg106102.html Am I missing something ? -- james On 3/21/2017 6:09 AM, Arnd Bergmann wrote: When LPFC is built-in but NVMe is a loadable

Re: [PATCHv4 2/4] tcmu: Fix wrongly calculating of the base_command_size

On 03/21/2017 04:36 AM, lixi...@cmss.chinamobile.com wrote: > From: Xiubo Li > > The t_data_nents and t_bidi_data_nents are the numbers of the > segments, but it couldn't be sure the block size equals to size > of the segment. > > For the worst case, all the blocks

Re: [PATCHv4 1/4] tcmu: Fix possible overwrite of t_data_sg's last iov[]

On 03/21/2017 04:36 AM, lixi...@cmss.chinamobile.com wrote: > From: Xiubo Li > > If there has BIDI data, its first iov[] will overwrite the last > iov[] for se_cmd->t_data_sg. > > To fix this, we can just increase the iov pointer, but this may > introuduce a new

Re: [PATCHv4 0/4] tcmu: bug fix and dynamic growing data area support

On 3/21/17 3:36 AM, lixi...@cmss.chinamobile.com wrote: From: Xiubo Li Changed for V4: - re-order the #3, #4 at the head. - merge most of the #5 to others. Changed for V3: - [PATCHv2 2/5] fix double usage of blocks and possible page fault call trace. -

Re: [PATCHv3 3/5] target/user: Fix possible overwrite of t_data_sg's last iov[]

On 03/20/2017 05:09 AM, lixi...@cmss.chinamobile.com wrote: > From: Xiubo Li > > If there has BIDI data, its first iov[] will overwrite the last > iov[] for se_cmd->t_data_sg. > > To fix this, we can just increase the iov pointer, but this may > introuduce a new

Re: [PATCHv3 4/6] scsi_error: do not escalate failed EH command

On Thu, Mar 16, 2017 at 12:53:45PM +0100, Hannes Reinecke wrote: >On 03/16/2017 12:01 PM, Benjamin Block wrote: >> On Wed, Mar 15, 2017 at 02:54:16PM +0100, Hannes Reinecke wrote: >>> On 03/14/2017 06:56 PM, Benjamin Block wrote: Hello Hannes, On Wed, Mar 01, 2017 at 10:15:18AM

Re: support ranges TRIM for libata

Hello, On Mon, Mar 20, 2017 at 04:43:12PM -0400, Christoph Hellwig wrote: > This series implements rangeѕ discard for ATA SSDs. Compared to the > initial NVMe support there are two things that complicate the ATA > support: > > - ATA only suports 16-bit long ranges > - the whole mess of

RE: [PATCH v2] scsi: storvsc: Add support for FC rport.

> -Original Message- > From: Cathy Avery [mailto:cav...@redhat.com] > Sent: Friday, March 17, 2017 8:18 AM > To: KY Srinivasan ; h...@infradead.org; Haiyang Zhang > ; j...@linux.vnet.ibm.com; > martin.peter...@oracle.com > Cc:

Re: [PATCH] sd: use async_probe cookie to avoid deadlocks

On 03/21/2017 04:33 PM, James Bottomley wrote: > On Tue, 2017-03-21 at 16:25 +0100, Hannes Reinecke wrote: >> On 03/21/2017 02:05 PM, James Bottomley wrote: >>> On Tue, 2017-03-21 at 13:14 +0100, Hannes Reinecke wrote: With the current design we're waiting for all async probes to finish

Re: [GIT PULL] SCSI fixes for 4.11-rc3

On Tue, Mar 21, 2017 at 11:08:51AM -0400, James Bottomley wrote: > Nine small fixes: the biggest is probably finally sorting out Kconfig > issues with lpfc nvme. I'm sorry to disappoint you but there's another fix from Arnd from today here: https://lkml.org/lkml/2017/3/21/308 Byte,

Re: [PATCH] sd: use async_probe cookie to avoid deadlocks

On 03/21/2017 02:05 PM, James Bottomley wrote: > On Tue, 2017-03-21 at 13:14 +0100, Hannes Reinecke wrote: >> With the current design we're waiting for all async probes to >> finish when removing any sd device. >> This might lead to a livelock where the 'remove' call is blocking >> for any probe

Re: [PATCH] sd: use async_probe cookie to avoid deadlocks

On Tue, 2017-03-21 at 16:25 +0100, Hannes Reinecke wrote: > On 03/21/2017 02:05 PM, James Bottomley wrote: > > On Tue, 2017-03-21 at 13:14 +0100, Hannes Reinecke wrote: > > > With the current design we're waiting for all async probes to > > > finish when removing any sd device. > > > This might

Re: [PATCH] sd: use async_probe cookie to avoid deadlocks

On 03/21/2017 02:33 PM, James Bottomley wrote: > On Tue, 2017-03-21 at 13:30 +, Bart Van Assche wrote: >> On Tue, 2017-03-21 at 09:05 -0400, James Bottomley wrote: >>> How does this preserve ordering? It looks like you have one cookie >>> per sdkp ... is there some sort of ordering guarantee

[GIT PULL] SCSI fixes for 4.11-rc3

Nine small fixes: the biggest is probably finally sorting out Kconfig issues with lpfc nvme. There are some performance fixes for megaraid and hpsa and a static checker fix. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes The short changelog

Re: [PATCH] sd: use async_probe cookie to avoid deadlocks

On Tue, 2017-03-21 at 09:33 -0400, James Bottomley wrote: > On Tue, 2017-03-21 at 13:30 +, Bart Van Assche wrote: > > On Tue, 2017-03-21 at 09:05 -0400, James Bottomley wrote: > > > How does this preserve ordering? It looks like you have one cookie > > > per sdkp ... is there some sort of

Re: [PATCH] sd: use async_probe cookie to avoid deadlocks

On Tue, 2017-03-21 at 13:30 +, Bart Van Assche wrote: > On Tue, 2017-03-21 at 09:05 -0400, James Bottomley wrote: > > How does this preserve ordering? It looks like you have one cookie > > per sdkp ... is there some sort of ordering guarantee I'm not > > seeing? > > Hello James, > > Since

Re: [PATCH] sd: use async_probe cookie to avoid deadlocks

On Tue, 2017-03-21 at 09:05 -0400, James Bottomley wrote: > How does this preserve ordering? It looks like you have one cookie per > sdkp ... is there some sort of ordering guarantee I'm not seeing? Hello James, Since the probe order depends on the order in which __async_probe() adds entries to

[PATCH] scsi: lpfc: fix linking against modular NVMe support

When LPFC is built-in but NVMe is a loadable module, we fail to link the kernel: drivers/scsi/built-in.o: In function `lpfc_nvme_create_localport': (.text+0x156a82): undefined reference to `nvme_fc_register_localport' drivers/scsi/built-in.o: In function `lpfc_nvme_destroy_localport':

Re: [PATCH] sd: use async_probe cookie to avoid deadlocks

On Tue, 2017-03-21 at 13:14 +0100, Hannes Reinecke wrote: > With the current design we're waiting for all async probes to > finish when removing any sd device. > This might lead to a livelock where the 'remove' call is blocking > for any probe calls to finish, and the probe calls are waiting for >

Re: [PATCH] sd: use async_probe cookie to avoid deadlocks

On Tue, 2017-03-21 at 13:14 +0100, Hannes Reinecke wrote: > With the current design we're waiting for all async probes to > finish when removing any sd device. > This might lead to a livelock where the 'remove' call is blocking > for any probe calls to finish, and the probe calls are waiting for >

[PATCH] scsi: ufs: remove the duplicated checking for supporting clkscaling

There are same conditions for checking whether supporting clkscaling or not. When ufshcd is supporting clkscaling, active_reqs should be decreased by two. Signed-off-by: Jaehoon Chung --- drivers/scsi/ufs/ufshcd.c | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH] sd: use async_probe cookie to avoid deadlocks

With the current design we're waiting for all async probes to finish when removing any sd device. This might lead to a livelock where the 'remove' call is blocking for any probe calls to finish, and the probe calls are waiting for a response, which will never be processes as the thread handling

[PATCH] BusLogic: Prevent write reordering when writing outgoing mailboxes

From: Alexander Eichner Make sure the compiler doesn't reorder the writes to the outgoing mailbox because the correct order does matter. Otherwise the controller might see a stale CCB handle under rare circumstances if the action code is written first and the

Re: [PATCH] enclosure: fix sysfs symlinks creation when using multipath

Dne 16.3.2017 v 19:49 James Bottomley napsal(a): > diff --git a/drivers/misc/enclosure.c b/drivers/misc/enclosure.c > index 65fed71..ae89082 100644 > --- a/drivers/misc/enclosure.c > +++ b/drivers/misc/enclosure.c > @@ -375,6 +375,7 @@ int enclosure_add_device(struct enclosure_device *edev, >

[PATCHv4 1/4] tcmu: Fix possible overwrite of t_data_sg's last iov[]

From: Xiubo Li If there has BIDI data, its first iov[] will overwrite the last iov[] for se_cmd->t_data_sg. To fix this, we can just increase the iov pointer, but this may introuduce a new memory leakage bug: If the se_cmd->data_length and

[PATCHv4 4/4] tcmu: Add global data block pool support

From: Xiubo Li For each target there will be one ring, when the target number grows larger and larger, it could eventually runs out of the system memories. In this patch for each target ring, for the cmd area the size will be limited to 8MB and for the data area

[PATCHv4 0/4] tcmu: bug fix and dynamic growing data area support

From: Xiubo Li Changed for V4: - re-order the #3, #4 at the head. - merge most of the #5 to others. Changed for V3: - [PATCHv2 2/5] fix double usage of blocks and possible page fault call trace. - [PATCHv2 5/5] fix a mistake. Changed for V2: - [PATCHv2 1/5]

[PATCHv4 2/4] tcmu: Fix wrongly calculating of the base_command_size

From: Xiubo Li The t_data_nents and t_bidi_data_nents are the numbers of the segments, but it couldn't be sure the block size equals to size of the segment. For the worst case, all the blocks are discontiguous and there will need the same number of iovecs, that's

[PATCHv4 3/4] tcmu: Add dynamic growing data area feature support

From: Xiubo Li Currently for the TCMU, the ring buffer size is fixed to 64K cmd area + 1M data area, and this will be bottlenecks for high iops. The struct tcmu_cmd_entry {} size is fixed about 112 bytes with iovec[N] & N <= 4, and the size of struct iovec is about

Re: [PATCH 24/29] drivers: convert iblock_req.pending from atomic_t to refcount_t

Hi Elena, On Mon, 2017-03-06 at 16:21 +0200, Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free >