Re: RFC: drop the T10 OSD code and its users

Christoph, > The only real user of the T10 OSD protocol, the pNFS object layout > driver never went to the point of having shipping products, and the > other two users (osdblk and exofs) were simple example of it's usage. > > The code has been mostly unmaintained for years and is getting in the

Re: remove REQ_OP_WRITE_SAME

Christoph, > Now that we are using REQ_OP_WRITE_ZEROES for all zeroing needs in the > kernel there is very little use left for REQ_OP_WRITE_SAME. We only > have two callers left, and both just export optional protocol features > to remote systems: DRBD and the target code. While I'm not

Re: [PATCH] block: fix bio_will_gap()

On Thu, Apr 13, 2017 at 04:22:22PM +, Bart Van Assche wrote: > On Fri, 2017-04-14 at 00:06 +0800, Ming Lei wrote: > > But if one rq starts with non-aligned buffer(the 1st bvec's > > bv_offset isn't zero) and if we allow to merge, it is quite > > difficult to respect sg gap limit, especially

Re: [PATCH] block: bios with an offset are always gappy

On Thu, Apr 13, 2017 at 10:35:17PM +0200, Andreas Mohr wrote: > On Thu, Apr 13, 2017 at 10:45:10PM +0800, Ming Lei wrote: > > + /* > > +* don't merge if the 1st bio starts with non-zero > > +* offset, otherwise it is quite difficult to respect > > +*

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

On Thu, Apr 13, 2017 at 09:59:57AM -0700, Bart Van Assche wrote: > On 04/12/17 19:20, Ming Lei wrote: > > On Wed, Apr 12, 2017 at 06:38:07PM +, Bart Van Assche wrote: > >> If the blk-mq core would always rerun a hardware queue if a block driver > >> returns BLK_MQ_RQ_QUEUE_BUSY then that would

Re: [PATCH 5/6] blk-mq: Add blk_mq_ops.show_rq()

On Tue, Apr 11, 2017 at 01:58:41PM -0700, Bart Van Assche wrote: > This new callback function will be used in the next patch to show > more information about SCSI requests. > > Signed-off-by: Bart Van Assche > Cc: Omar Sandoval > Cc: Hannes Reinecke

Re: [PATCH 4/6] blk-mq: Show operation, cmd_flags and rq_flags names

On Tue, Apr 11, 2017 at 01:58:40PM -0700, Bart Van Assche wrote: > Show the operation name, .cmd_flags and .rq_flags as names instead > of numbers. > > Signed-off-by: Bart Van Assche > Cc: Omar Sandoval > Cc: Hannes Reinecke I like

RE: [PATCH] block-mq: set both block queue and hardware queue restart bit for restart

> -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@sandisk.com] > Sent: Monday, April 10, 2017 4:48 PM > To: linux-ker...@vger.kernel.org; linux-block@vger.kernel.org; KY Srinivasan > ; Long Li ; ax...@kernel.dk > Cc: Stephen

Re: [PATCH 3/6] blk-mq: Make blk_flags_show() callers append a newline character

On Tue, Apr 11, 2017 at 01:58:39PM -0700, Bart Van Assche wrote: > This patch does not change any functionality but makes it possible > to produce a single line of output with multiple flag-to-name > translations. > > Signed-off-by: Bart Van Assche > Cc: Omar Sandoval

Re: [PATCH 1/6] blk-mq: Do not invoke queue operations on a dead queue

On Thu, 2017-04-13 at 16:01 -0700, Omar Sandoval wrote: > On Tue, Apr 11, 2017 at 01:58:37PM -0700, Bart Van Assche wrote: > > The blk-mq debugfs attributes are removed after blk_cleanup_queue() > > has finished. Since running a queue after a queue has entered the > > "dead" state is not allowed,

Re: [PATCH 2/6] blk-mq: Move the "state" debugfs attribute one level down

On Tue, Apr 11, 2017 at 01:58:38PM -0700, Bart Van Assche wrote: > Move the "state" attribute from the top level to the "mq" directory > as requested by Omar. > > Signed-off-by: Bart Van Assche > Cc: Omar Sandoval > Cc: Hannes Reinecke

Re: [PATCH 1/6] blk-mq: Do not invoke queue operations on a dead queue

On Tue, Apr 11, 2017 at 01:58:37PM -0700, Bart Van Assche wrote: > The blk-mq debugfs attributes are removed after blk_cleanup_queue() > has finished. Since running a queue after a queue has entered the > "dead" state is not allowed, disallow this. This patch avoids that > an attempt to run a dead

Re: [PATCH] block: bios with an offset are always gappy

On Thu, Apr 13, 2017 at 10:45:10PM +0800, Ming Lei wrote: > + /* > + * don't merge if the 1st bio starts with non-zero > + * offset, otherwise it is quite difficult to respect > + * sg gap limit. We work hard to merge huge of small > +

Re: [PATCH 08/25] scsi: fix fast-fail for non-passthrough requests

On Thu, 2017-04-06 at 17:39 +0200, Christoph Hellwig wrote: > Currently error is always 0 for non-passthrough requests when reaching the > scsi_noretry_cmd check in scsi_io_completion, which effectively disables > all fastfail logic. Fix this by having a single call to >

Re: [PATCH 06/25] virtio: fix spelling of virtblk_scsi_request_done

On Thu, 2017-04-06 at 17:39 +0200, Christoph Hellwig wrote: > [ ... ] Reviewed-by: Bart Van Assche

Re: [PATCH 02/25] block: remove the blk_execute_rq return value

On Thu, 2017-04-06 at 17:39 +0200, Christoph Hellwig wrote: > diff --git a/fs/nfsd/blocklayout.c b/fs/nfsd/blocklayout.c > index 92b4b41d19d2..4b72fdf67548 100644 > --- a/fs/nfsd/blocklayout.c > +++ b/fs/nfsd/blocklayout.c > @@ -242,8 +242,8 @@ static int nfsd4_scsi_identify_device(struct

Re: [PATCH 01/25] remove the mg_disk driver

On Thu, 2017-04-06 at 17:39 +0200, Christoph Hellwig wrote: > This drivers was added in 2008, but as far as a I can tell we never had a > single platform that actually registered resources for the platform driver. > > It's also been unmaintained for a long time and apparently has a ATA mode >

Re: [PATCH] lightnvm: fix some WARN() messages

On 04/13/2017 09:36 PM, Dan Carpenter wrote: WARN_ON() takes a condition, not an error message. I slightly tweaked some conditions so hopefully it's more clear. Signed-off-by: Dan Carpenter diff --git a/drivers/lightnvm/pblk-read.c b/drivers/lightnvm/pblk-read.c

Re: [PATCH] lightnvm: fix some error code in pblk-init.c

On 04/13/2017 09:35 PM, Dan Carpenter wrote: There were a bunch of places in pblk_lines_init() where we didn't set an error code. And in pblk_writer_init() we accidentally return 1 instead of a correct error code, which would result in a Oops later. Fixes: 11a5d6fdf919 ("lightnvm: physical

[PATCH block-tree] net: off by one in inet6_pton()

If "scope_len" is sizeof(scope_id) then we would put the NUL terminator one space beyond the end of the buffer. Fixes: b1a951fe469e ("net/utils: generic inet_pton_with_scope helper") Signed-off-by: Dan Carpenter --- This one goes through Jens' tree not through net-dev.

[PATCH] lightnvm: fix some WARN() messages

WARN_ON() takes a condition, not an error message. I slightly tweaked some conditions so hopefully it's more clear. Signed-off-by: Dan Carpenter diff --git a/drivers/lightnvm/pblk-read.c b/drivers/lightnvm/pblk-read.c index eff0982c076f..bce7ed5fc73f 100644 ---

Re: [PATCH] lightnvm: pblk-gc: fix an error pointer dereference in init

On 04/13/2017 09:32 PM, Dan Carpenter wrote: These labels are reversed so we could end up dereferencing an error pointer or leaking. Fixes: 7f347ba6bb3a ("lightnvm: physical block device (pblk) target") Signed-off-by: Dan Carpenter diff --git

[PATCH] lightnvm: fix some error code in pblk-init.c

There were a bunch of places in pblk_lines_init() where we didn't set an error code. And in pblk_writer_init() we accidentally return 1 instead of a correct error code, which would result in a Oops later. Fixes: 11a5d6fdf919 ("lightnvm: physical block device (pblk) target") Signed-off-by: Dan

[PATCH] lightnvm: pblk-gc: fix an error pointer dereference in init

These labels are reversed so we could end up dereferencing an error pointer or leaking. Fixes: 7f347ba6bb3a ("lightnvm: physical block device (pblk) target") Signed-off-by: Dan Carpenter diff --git a/drivers/lightnvm/pblk-gc.c b/drivers/lightnvm/pblk-gc.c index

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

On 04/12/17 19:20, Ming Lei wrote: > On Wed, Apr 12, 2017 at 06:38:07PM +, Bart Van Assche wrote: >> If the blk-mq core would always rerun a hardware queue if a block driver >> returns BLK_MQ_RQ_QUEUE_BUSY then that would cause 100% of a single CPU core > > It won't casue 100% CPU utilization

Re: [PATCH] block: fix bio_will_gap()

On Fri, 2017-04-14 at 00:06 +0800, Ming Lei wrote: > But if one rq starts with non-aligned buffer(the 1st bvec's > bv_offset isn't zero) and if we allow to merge, it is quite > difficult to respect sg gap limit, especially the segment > can't be at maximum segment size, otherwise the segment >

[PATCH] block: fix bio_will_gap()

Now commit 729204ef49ec("block: relax check on sg gap") allows us to merge bios if both are physically contiguous, this change can merge huge of small bios in use case of mkfs, for example, mkfs.ntfs running time can be decreased to ~1/10. But if one rq starts with non-aligned buffer(the 1st

Re: [PATCH] block: bios with an offset are always gappy

On Thu, Apr 13, 2017 at 10:45:10PM +0800, Ming Lei wrote: > On Thu, Apr 13, 2017 at 01:53:28PM +0200, Johannes Thumshirn wrote: > > On Thu, Apr 13, 2017 at 06:02:21PM +0800, Ming Lei wrote: > > > On Thu, Apr 13, 2017 at 10:06:29AM +0200, Johannes Thumshirn wrote: > > > > Doing a mkfs.btrfs on a

Re: [PATCH] block: bios with an offset are always gappy

On Thu, Apr 13, 2017 at 01:53:28PM +0200, Johannes Thumshirn wrote: > On Thu, Apr 13, 2017 at 06:02:21PM +0800, Ming Lei wrote: > > On Thu, Apr 13, 2017 at 10:06:29AM +0200, Johannes Thumshirn wrote: > > > Doing a mkfs.btrfs on a (qemu emulated) PCIe NVMe causes a kernel panic > > > in

Re: [PATCH] block: bios with an offset are always gappy

On Thu, Apr 13, 2017 at 02:20:10PM +0200, Johannes Thumshirn wrote: > On Thu, Apr 13, 2017 at 08:11:40PM +0800, Ming Lei wrote: > > Ok, could you apply the attached debug patch and collect the > > ftrace log? (ftrace_dump_on_oops need to be passed to kernel cmd line). > Thanks Johannes very much

Re: Outstanding MQ questions from MMC

On Fri, Mar 31, 2017 at 10:43 AM, Arnd Bergmann wrote: > On Thu, Mar 30, 2017 at 6:39 PM, Ulf Hansson wrote: >> On 30 March 2017 at 14:42, Arnd Bergmann wrote: >>> On Wed, Mar 29, 2017 at 5:09 AM, Linus Walleij

Re: [PATCH v4 0/6] Avoid that scsi-mq and dm-mq queue processing stalls sporadically

On Wed, Apr 12, 2017 at 06:11:25PM +, Bart Van Assche wrote: > On Wed, 2017-04-12 at 12:55 +0200, Benjamin Block wrote: > > On Fri, Apr 07, 2017 at 11:16:48AM -0700, Bart Van Assche wrote: > > > The six patches in this patch series fix the queue lockup I reported > > > recently on the

Re: [PATCH] block: bios with an offset are always gappy

On Thu, Apr 13, 2017 at 01:53:28PM +0200, Johannes Thumshirn wrote: > On Thu, Apr 13, 2017 at 06:02:21PM +0800, Ming Lei wrote: > > On Thu, Apr 13, 2017 at 10:06:29AM +0200, Johannes Thumshirn wrote: > > > Doing a mkfs.btrfs on a (qemu emulated) PCIe NVMe causes a kernel panic > > > in

Re: [PATCH] block: bios with an offset are always gappy

On Thu, Apr 13, 2017 at 06:02:21PM +0800, Ming Lei wrote: > On Thu, Apr 13, 2017 at 10:06:29AM +0200, Johannes Thumshirn wrote: > > Doing a mkfs.btrfs on a (qemu emulated) PCIe NVMe causes a kernel panic > > in nvme_setup_prps() because the dma_len will drop below zero but the > > length not. > >

Re: [PATCH] block: bios with an offset are always gappy

On Thu, Apr 13, 2017 at 06:02:21PM +0800, Ming Lei wrote: > Could you try the following patch to see if it fixes your issue? Sure, jsut have a short lunch break and then I'll report back. -- Johannes Thumshirn Storage jthumsh...@suse.de

Re: [PATCH] block: bios with an offset are always gappy

On Thu, Apr 13, 2017 at 10:06:29AM +0200, Johannes Thumshirn wrote: > Doing a mkfs.btrfs on a (qemu emulated) PCIe NVMe causes a kernel panic > in nvme_setup_prps() because the dma_len will drop below zero but the > length not. Looks I can't reproduce the issue in QEMU(32G nvme, either

Re: [PATCH] block: bios with an offset are always gappy

On Thu, Apr 13, 2017 at 11:48:35AM +0200, Christoph Hellwig wrote: > On Thu, Apr 13, 2017 at 10:06:29AM +0200, Johannes Thumshirn wrote: > > Doing a mkfs.btrfs on a (qemu emulated) PCIe NVMe causes a kernel panic > > in nvme_setup_prps() because the dma_len will drop below zero but the > > length

Re: [PATCH] block: bios with an offset are always gappy

On Thu, Apr 13, 2017 at 11:48:35AM +0200, Christoph Hellwig wrote: > I think we should also turns this into a WARN_ON_ONCE + error return.. > > But do you have an exact btrfsprogs version and command line? I do a lot > of testing that involves mkfs.btrfs on nvme and haven't seen it.. Sure,

Re: [PATCH] block: bios with an offset are always gappy

On Thu, Apr 13, 2017 at 10:06:29AM +0200, Johannes Thumshirn wrote: > Doing a mkfs.btrfs on a (qemu emulated) PCIe NVMe causes a kernel panic > in nvme_setup_prps() because the dma_len will drop below zero but the > length not. I think we should also turns this into a WARN_ON_ONCE + error

Re: [PATCH 2/3] block: remove blk_end_request_cur

On Wed, Apr 12, 2017 at 12:13:58PM +0200, Christoph Hellwig wrote: > This function is not used anywhere in the kernel. > > Signed-off-by: Christoph Hellwig > --- Looks good, though one could argue it can be merged into the last patch. Reviewed-by: Johannes Thumshirn

Re: [PATCH 1/3] block: remove blk_end_request_err and __blk_end_request_err

On Wed, Apr 12, 2017 at 12:13:57PM +0200, Christoph Hellwig wrote: > Both functions are entirely unused. > > Signed-off-by: Christoph Hellwig > --- Looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn

[PATCH] block: bios with an offset are always gappy

Doing a mkfs.btrfs on a (qemu emulated) PCIe NVMe causes a kernel panic in nvme_setup_prps() because the dma_len will drop below zero but the length not. A git bisect tracked the behaviour down to commit 729204ef49ec ("block: relax check on sg gap"). Since commit 729204ef49ec a bio's offsets are