Re: [PATCH BUGFIX V2] block, bfq: update wr_busy_queues if needed on a queue split

> Il giorno 27 giu 2017, alle ore 20:29, Jens Axboe ha > scritto: > > On 06/27/2017 12:27 PM, Paolo Valente wrote: >> >>> Il giorno 27 giu 2017, alle ore 16:41, Jens Axboe ha >>> scritto: >>> >>> On 06/27/2017 12:09 AM, Paolo Valente wrote: > Il

Re: [PATCH] sd: add support for TCG OPAL self encrypting disks

Tejun, >> Looks good to me. I'll queue it up for 4.13 as soon as Linus has pulled >> in the ata bits. > > I can route it through libata tree w/ your ack if that's more convenient. I don't think it will cause any headaches. I'm just a bit cautious since I already have a ton of conflicts in

Re: [BUG] Deadlock due due to interactions of block, RCU, and cpu offline

On Tue, Jun 27, 2017 at 04:32:09PM -0600, Jeffrey Hugo wrote: > On 6/22/2017 9:34 PM, Paul E. McKenney wrote: > >On Wed, Jun 21, 2017 at 09:18:53AM -0700, Paul E. McKenney wrote: > >>No worries, and I am very much looking forward to seeing the results of > >>your testing. > > > >And please see

LightNVM pblk: read/write of random kernel memory

Hi, I'm currently having trouble with LightNVM pblk with kernel 4.12-rc7 on Ubuntu 16.04.2 x86_64 in a Qemu VM using latest https://github.com/OpenChannelSSD/qemu-nvme . I'm creating a pblk device inside the VM with the following command: nvme lvnm create -d nvme0n1 --lun-begin=0 --lun-end=0 -n

Re: [BUG] Deadlock due due to interactions of block, RCU, and cpu offline

On 6/22/2017 9:34 PM, Paul E. McKenney wrote: On Wed, Jun 21, 2017 at 09:18:53AM -0700, Paul E. McKenney wrote: No worries, and I am very much looking forward to seeing the results of your testing. And please see below for an updated patch based on LKML review and more intensive testing. I

Re: [PATCH 0/5] v3 block subsystem refcounter conversions

On Tue, Jun 27, 2017 at 6:26 AM, Jens Axboe wrote: > On 06/27/2017 05:39 AM, Elena Reshetova wrote: >> Changes in v3: >> No changes in patches apart from trivial rebases, but now by >> default refcount_t = atomic_t and uses all atomic standard operations >> unless

Re: [PATCH BUGFIX V2] block, bfq: update wr_busy_queues if needed on a queue split

On 06/27/2017 12:27 PM, Paolo Valente wrote: > >> Il giorno 27 giu 2017, alle ore 16:41, Jens Axboe ha >> scritto: >> >> On 06/27/2017 12:09 AM, Paolo Valente wrote: >>> Il giorno 19 giu 2017, alle ore 13:43, Paolo Valente ha scritto:

Re: [PATCH BUGFIX V2] block, bfq: update wr_busy_queues if needed on a queue split

> Il giorno 27 giu 2017, alle ore 16:41, Jens Axboe ha > scritto: > > On 06/27/2017 12:09 AM, Paolo Valente wrote: >> >>> Il giorno 19 giu 2017, alle ore 13:43, Paolo Valente >>> ha scritto: >>> >>> This commit fixes a bug triggered by a

Re: block: spread MSI(-X) vectors to all possible CPUs

On 06/26/2017 04:20 AM, Christoph Hellwig wrote: > Hi all, > > this series contains the left-over block bits to spread the MSI-X > vectors over all CPU. Thomas already rewrote and then merged the > irq bits into the tip irq/core branch, and this is the remainder. > > As there are no

Re: move bounce limits settings into the drivers

On 06/19/2017 01:26 AM, Christoph Hellwig wrote: > Currently we still default to a bounce all highmem setting for block > drivers. This series defaults to no bouncing and instead adds call > to blk_queue_bounce_limit to those drivers that need it. It also > has a few cleanups in that area.

Re: [PATCH blktests v2 0/2] Test I/O to device while resetting PCI

On Tue, Jun 27, 2017 at 03:42:55PM +0200, Johannes Thumshirn wrote: > Changes to v1: > * Ignore fio errors > * add an additional sleep .2 after re-enabling the pci device > * directly call readlink in _get_pci_dev_from_blkdev() > > Johannes Thumshirn (2): > rc: add helpers to handle PCI test

Re: [PATCH v2 11/51] md: raid1: initialize bvec table via bio_add_page()

On Tue, Jun 27, 2017 at 05:36:39PM +0800, Guoqing Jiang wrote: > > > On 06/26/2017 08:09 PM, Ming Lei wrote: > > We will support multipage bvec soon, so initialize bvec > > table using the standardy way instead of writing the > > talbe directly. Otherwise it won't work any more once > >

Re: [PATCH 1/9] fs: add fcntl() interface for setting/getting write life time hints

On 06/27/2017 08:42 AM, Christoph Hellwig wrote: > The API looks ok, but the code could use some cleanups. What do > you think about the incremental patch below: > > It refactors various manipulations, and stores the write hint right > in the iocb as there is a 4 byte hole (this will need some

Re: [PATCH 1/9] fs: add fcntl() interface for setting/getting write life time hints

On Tue, Jun 27, 2017 at 09:09:48AM -0600, Jens Axboe wrote: > On 06/27/2017 08:42 AM, Christoph Hellwig wrote: > > The API looks ok, but the code could use some cleanups. What do > > you think about the incremental patch below: > > > > It refactors various manipulations, and stores the write

Re: [PATCH 1/9] fs: add fcntl() interface for setting/getting write life time hints

On 06/27/2017 09:16 AM, Christoph Hellwig wrote: > On Tue, Jun 27, 2017 at 09:09:48AM -0600, Jens Axboe wrote: >> On 06/27/2017 08:42 AM, Christoph Hellwig wrote: >>> The API looks ok, but the code could use some cleanups. What do >>> you think about the incremental patch below: >>> >>> It

Re: [PATCH 3/9] blk-mq: expose write hints through debugfs

On Mon, Jun 26, 2017 at 09:37:54AM -0600, Jens Axboe wrote: > Useful to verify that things are working the way they should. > Reading the file will return number of kb written with each > write hint. Writing the file will reset the statistics. No care > is taken to ensure that we don't race on

Re: [PATCH v7 16/22] block: convert to errseq_t based writeback error tracking

On Mon, Jun 26, 2017 at 10:34:18AM -0400, Jeff Layton wrote: > The bigger question is -- what about more complex filesystems like > ext4? There are a couple of cases where we can return -EIO or -EROFS on > fsync before filemap_write_and_wait_range is ever called. Like this one > for instance: >

Re: [PATCH 3/9] blk-mq: expose write hints through debugfs

On 06/27/2017 09:17 AM, Christoph Hellwig wrote: > On Mon, Jun 26, 2017 at 09:37:54AM -0600, Jens Axboe wrote: >> Useful to verify that things are working the way they should. >> Reading the file will return number of kb written with each >> write hint. Writing the file will reset the statistics.

Re: [PATCH 1/9] fs: add fcntl() interface for setting/getting write life time hints

On 06/27/2017 08:57 AM, Christoph Hellwig wrote: > On Tue, Jun 27, 2017 at 08:55:02AM -0600, Jens Axboe wrote: >> BTW, that patch does not look like an incremental patch, what's >> this against? > > The patch I'm replying to, without the other ones. Looks like a replacement patch, not

Re: [PATCH 1/9] fs: add fcntl() interface for setting/getting write life time hints

On Tue, Jun 27, 2017 at 08:55:02AM -0600, Jens Axboe wrote: > BTW, that patch does not look like an incremental patch, what's > this against? The patch I'm replying to, without the other ones.

Re: [PATCH 9/9] nvme: add support for streams and directives

On 06/27/2017 08:46 AM, Jens Axboe wrote: > On 06/27/2017 08:44 AM, Christoph Hellwig wrote: >> On Tue, Jun 27, 2017 at 08:16:49AM -0600, Jens Axboe wrote: >>> But we have to handle it, not doing so would be fragile. So our >>> options are: >>> >>> 1) Keep the stream_mappings[] array. It's simple,

Re: [PATCH 1/9] fs: add fcntl() interface for setting/getting write life time hints

On 06/27/2017 08:42 AM, Christoph Hellwig wrote: > The API looks ok, but the code could use some cleanups. What do > you think about the incremental patch below: > > It refactors various manipulations, and stores the write hint right > in the iocb as there is a 4 byte hole (this will need some

Re: [PATCH 4/9] fs: add O_DIRECT support for sending down write life time hints

> - bio_set_op_attrs(bio, REQ_OP_WRITE, REQ_SYNC | > REQ_IDLE); > + bio_set_op_attrs(bio, REQ_OP_WRITE, > + REQ_SYNC | REQ_IDLE); bio->bi_opf = REQ_OP_WRITE | REQ_SYNC | REQ_IDLE;

Re: [PATCH 1/9] fs: add fcntl() interface for setting/getting write life time hints

On Tue, Jun 27, 2017 at 07:42:55AM -0700, Christoph Hellwig wrote: > The API looks ok, but the code could use some cleanups. What do > you think about the incremental patch below: > > It refactors various manipulations, and stores the write hint right > in the iocb as there is a 4 byte hole

Re: [PATCH 9/9] nvme: add support for streams and directives

On 06/27/2017 08:44 AM, Christoph Hellwig wrote: > On Tue, Jun 27, 2017 at 08:16:49AM -0600, Jens Axboe wrote: >> But we have to handle it, not doing so would be fragile. So our >> options are: >> >> 1) Keep the stream_mappings[] array. It's simple, and it'll work >>for any number of streams.

Re: [PATCH 1/9] fs: add fcntl() interface for setting/getting write life time hints

The API looks ok, but the code could use some cleanups. What do you think about the incremental patch below: It refactors various manipulations, and stores the write hint right in the iocb as there is a 4 byte hole (this will need some minor adjustments in the next patches): diff --git

Re: [PATCH 9/9] nvme: add support for streams and directives

On Tue, Jun 27, 2017 at 08:16:49AM -0600, Jens Axboe wrote: > But we have to handle it, not doing so would be fragile. So our > options are: > > 1) Keep the stream_mappings[] array. It's simple, and it'll work >for any number of streams. > > 2) Kill stream_mappings[] and just do the MOD

Re: [PATCH BUGFIX V2] block, bfq: update wr_busy_queues if needed on a queue split

On 06/27/2017 12:09 AM, Paolo Valente wrote: > >> Il giorno 19 giu 2017, alle ore 13:43, Paolo Valente >> ha scritto: >> >> This commit fixes a bug triggered by a non-trivial sequence of >> events. These events are briefly described in the next two >> paragraphs. The

Re: [PATCH V3] lightnvm: if LUNs are already allocated fix return

On 06/27/2017 05:55 AM, Rakesh Pandit wrote: > While creating new device with NVM_DEV_CREATE if LUNs are already > allocated ioctl would return -ENOMEM which is wrong. This patch > propagates -EBUSY from nvm_reserve_luns which is correct response. Thanks, applied for 4.13. -- Jens Axboe

Re: [PATCH 9/9] nvme: add support for streams and directives

On 06/27/2017 08:11 AM, Christoph Hellwig wrote: > On Mon, Jun 26, 2017 at 07:56:22AM -0600, Jens Axboe wrote: >>> - do we even need the < 4 streams fallback now that they are global >>>instead of per-ns instead of just disabling the feature for now? >> >> Maybe the device only supports 2? or

Re: [PATCH 9/9] nvme: add support for streams and directives

On Mon, Jun 26, 2017 at 07:56:22AM -0600, Jens Axboe wrote: > > - do we even need the < 4 streams fallback now that they are global > >instead of per-ns instead of just disabling the feature for now? > > Maybe the device only supports 2? or 3? My crystal ball indicates that those are

[PATCH blktests v2 2/2] block/011: Perform PCI reset while doing IO

This test-case performs I/O with fio while doing PCI disable/enable cycles. In the results we don't care for I/O errors but for hiccups in dmesg only. Signed-off-by: Johannes Thumshirn --- tests/block/011 | 55 +

[PATCH blktests v2 0/2] Test I/O to device while resetting PCI

Changes to v1: * Ignore fio errors * add an additional sleep .2 after re-enabling the pci device * directly call readlink in _get_pci_dev_from_blkdev() Johannes Thumshirn (2): rc: add helpers to handle PCI test devices block/011: Perform PCI reset while doing IO common/rc | 13

[PATCH blktests v2 1/2] rc: add helpers to handle PCI test devices

Add two helpers to check whether a device is attached via PCI and to get the PCI device from a TEST_DEV Signed-off-by: Johannes Thumshirn --- common/rc | 13 + 1 file changed, 13 insertions(+) diff --git a/common/rc b/common/rc index 088422ce909b..28116b0fc308

Re: [PATCH 0/5] v3 block subsystem refcounter conversions

On 06/27/2017 05:39 AM, Elena Reshetova wrote: > Changes in v3: > No changes in patches apart from trivial rebases, but now by > default refcount_t = atomic_t and uses all atomic standard operations > unless CONFIG_REFCOUNT_FULL is enabled. This is a compromize for the > systems that are critical

Re: [PATCH V3] lightnvm: if LUNs are already allocated fix return

On Tue, Jun 27, 2017 at 1:55 PM, Rakesh Pandit wrote: > While creating new device with NVM_DEV_CREATE if LUNs are already > allocated ioctl would return -ENOMEM which is wrong. This patch > propagates -EBUSY from nvm_reserve_luns which is correct response. > > Fixes: ade69e243

[PATCH V3] lightnvm: if LUNs are already allocated fix return

While creating new device with NVM_DEV_CREATE if LUNs are already allocated ioctl would return -ENOMEM which is wrong. This patch propagates -EBUSY from nvm_reserve_luns which is correct response. Fixes: ade69e243 ("lightnvm: merge gennvm with core") Signed-off-by: Rakesh Pandit

[PATCH 2/5] block: convert blk_queue_tag.refcnt from atomic_t to refcount_t

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. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 3/5] block: convert blkcg_gq.refcnt from atomic_t to refcount_t

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. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 5/5] block: convert bsg_device.ref_count from atomic_t to refcount_t

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. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 1/5] block: convert bio.__bi_cnt from atomic_t to refcount_t

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. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 0/5] v3 block subsystem refcounter conversions

Changes in v3: No changes in patches apart from trivial rebases, but now by default refcount_t = atomic_t and uses all atomic standard operations unless CONFIG_REFCOUNT_FULL is enabled. This is a compromize for the systems that are critical on performance and cannot accept even slight delay on the

[PATCH 4/5] block: convert io_context.active_ref from atomic_t to refcount_t

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. Signed-off-by: Elena Reshetova Signed-off-by:

Re: [PATCH V2] lightnvm: if LUNs are already allocated fix return

On Tue, Jun 27, 2017 at 01:27:40PM +0200, Frans Klaver wrote: > On Tue, Jun 27, 2017 at 1:23 PM, Rakesh Pandit wrote: > > On Tue, Jun 27, 2017 at 01:01:22PM +0200, Frans Klaver wrote: > >> On Tue, Jun 27, 2017 at 12:43 PM, Rakesh Pandit wrote: > >> > While

Re: [PATCH V2] lightnvm: if LUNs are already allocated fix return

On Tue, Jun 27, 2017 at 1:23 PM, Rakesh Pandit wrote: > On Tue, Jun 27, 2017 at 01:01:22PM +0200, Frans Klaver wrote: >> On Tue, Jun 27, 2017 at 12:43 PM, Rakesh Pandit wrote: >> > While creating new device with NVM_DEV_CREATE if LUNs are already >> >

Re: [PATCH V2] lightnvm: if LUNs are already allocated fix return

On Tue, Jun 27, 2017 at 01:01:22PM +0200, Frans Klaver wrote: > On Tue, Jun 27, 2017 at 12:43 PM, Rakesh Pandit wrote: > > While creating new device with NVM_DEV_CREATE if LUNs are already > > allocated ioctl would return -ENOMEM which is wrong. This patch > > propagates

Re: [PATCH V2] lightnvm: if LUNs are already allocated fix return

On Tue, Jun 27, 2017 at 12:43 PM, Rakesh Pandit wrote: > While creating new device with NVM_DEV_CREATE if LUNs are already > allocated ioctl would return -ENOMEM which is wrong. This patch > propagates -EBUSY from nvm_reserve_luns which is correct response. > > Fixes:

[PATCH V2] lightnvm: if LUNs are already allocated fix return

While creating new device with NVM_DEV_CREATE if LUNs are already allocated ioctl would return -ENOMEM which is wrong. This patch propagates -EBUSY from nvm_reserve_luns which is correct response. Fixes: ade69e243 ("lightnvm: merge gennvm with core") Signed-off-by: Rakesh Pandit

Re: [PATCH] ligtnvm: if LUNs are already allocated fix return

Hi Frans, On Tue, Jun 27, 2017 at 11:06:44AM +0200, Frans Klaver wrote: > On Tue, Jun 27, 2017 at 10:39 AM, Matias Bjørling wrote: > > From: Rakesh Pandit > > > > While creating new device with NVM_DEV_CREATE if LUNs are already > > allocated ioctl would return -ENOMEM which

Re: [PATCH v2 11/51] md: raid1: initialize bvec table via bio_add_page()

On 06/26/2017 08:09 PM, Ming Lei wrote: We will support multipage bvec soon, so initialize bvec table using the standardy way instead of writing the talbe directly. Otherwise it won't work any more once multipage bvec is enabled. Cc: Shaohua Li Cc: linux-r...@vger.kernel.org

Re: [PATCH] ligtnvm: if LUNs are already allocated fix return

On Tue, Jun 27, 2017 at 10:39 AM, Matias Bjørling wrote: > From: Rakesh Pandit > > While creating new device with NVM_DEV_CREATE if LUNs are already > allocated ioctl would return -ENOMEM which is wrong. This patch > propagates -EBUSY from nvm_reserve_luns

[PATCH] ligtnvm: if LUNs are already allocated fix return

From: Rakesh Pandit While creating new device with NVM_DEV_CREATE if LUNs are already allocated ioctl would return -ENOMEM which is wrong. This patch propagates -EBUSY from nvm_reserve_luns which is correct response. Fixes: ade69e243 ("lightnvm: merge gennvm with core")

[PATCH] Small patch for 4.13 window

Hi Jens, Thanks for picking up the pblk changes. I have just a small one that wasn't part of the batch. Would you pick this one up as well for the 4.13 window? -Matias Rakesh Pandit (1): ligtnvm: if LUNs are already allocated fix return drivers/lightnvm/core.c | 11 ++- 1 file

Re: [PATCH 00/20] LightNVM: pblk patches for 4.13

> On 27 Jun 2017, at 00.29, Jens Axboe wrote: > > On Mon, Jun 26 2017, Javier González wrote: >> Hi Matias, >> >> Here you have the pblk patchset for this window. >> >> Apart from small fixes for LightNVM core and pblk, there are three >> relevant changes: >> >> - Metadata

Re: [PATCH v2 16/51] block: bounce: avoid direct access to bvec table

On Mon, Jun 26, 2017 at 11:12:11PM -0700, Matthew Wilcox wrote: > On Mon, Jun 26, 2017 at 08:09:59PM +0800, Ming Lei wrote: > > bio_for_each_segment_all(bvec, bio, i) { > > - org_vec = bio_orig->bi_io_vec + i + start; > > - > > - if (bvec->bv_page == org_vec->bv_page) > > -

[PATCH, RESEND] ARM: Fix rd_size declaration

The global variable 'rd_size' is declared as 'int' in source file arch/arm/kernel/atags_parse.c and as 'unsigned long' in drivers/block/brd.c. Fix this inconsistency. Additionally, remove the declarations of rd_image_start, rd_prompt and rd_doload from parse_tag_ramdisk() since these duplicate

Re: [PATCH blktests 2/2] block/011: Perform PCI reset while doing IO

On Mon, Jun 26, 2017 at 02:27:24PM -0700, Omar Sandoval wrote: [...] > > + > > + while kill -0 $! 2>/dev/null; do > > + echo 0 > "/sys/bus/pci/devices/${pdev}/enable" > > + sleep .2 > > + echo 1 > "/sys/bus/pci/devices/${pdev}/enable" > > Test looks good, but one

Re: [PATCH v2 16/51] block: bounce: avoid direct access to bvec table

On Mon, Jun 26, 2017 at 08:09:59PM +0800, Ming Lei wrote: > bio_for_each_segment_all(bvec, bio, i) { > - org_vec = bio_orig->bi_io_vec + i + start; > - > - if (bvec->bv_page == org_vec->bv_page) > - continue; > + orig_vec =

Re: [PATCH BUGFIX V2] block, bfq: update wr_busy_queues if needed on a queue split

> Il giorno 19 giu 2017, alle ore 13:43, Paolo Valente > ha scritto: > > This commit fixes a bug triggered by a non-trivial sequence of > events. These events are briefly described in the next two > paragraphs. The impatiens, or those who are familiar with queue >