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
> situations
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 to say: blocks == iovs.
So here
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 16 bytes.
If N == 0, the rati
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] just fixes some small spelling and
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 se_cmd->t_bidi_data_sg->length are all not aligned up to
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 the size will be
limited to 256K
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,
> i
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 controller happens to
read the mailbo
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
the
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 a/drivers/scsi/ufs/ufshcd.c b/d
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
>
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
>
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':
(.text+0x156
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
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 t
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 ord
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 i
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
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 lea
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 ca
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,
Johann
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 w
> -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: step...@networkplumber.org; dan.carpen...@oracle.com;
> de...@
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 generat
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 +0100
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 memory leakage bug: If the se_cmd
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.
- [PATCHv2 5/5] fix a mistake.
Changed
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 memory leakage bug: If the se_cmd
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 are discontiguous and there
>
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 m
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 a
31 matches
Mail list logo
