Re: [PATCH] block: note about cloned bios and bio_for_each_segment_all

On Fri, Jul 14, 2017 at 08:22:31AM -0600, Jens Axboe wrote: > /* > * drivers should _never_ use the all version - the bio may have been split > - * before it got to the driver and the driver won't own all of it > + * before it got to the driver and the driver won't own all of it. > + * > + *

[PATCH 6/6] blk-mq: unexport APIs for start/stop queues

Now no one uses these APIs anymore, so unexport them. Signed-off-by: Ming Lei --- block/blk-mq.c | 83 ++ block/blk-mq.h | 1 + include/linux/blk-mq.h | 8 - 3 files changed, 3 insertions(+), 89

[PATCH 5/6] block: use BLK_MQ_F_AUTO_RESTART on virtio-blk and xen-blkfront

Now blk-mq implements such function via BLK_MQ_F_AUTO_RESTART, so just use that and remove related code in virtio-blk and xen-blkfront. Signed-off-by: Ming Lei --- drivers/block/virtio_blk.c | 8 +--- drivers/block/xen-blkfront.c | 15 ++- 2 files

[PATCH 4/6] blk-mq: introduce auto restart

Both xen-blkfront and virito-blk stops queue when the queue becomes busy, and restarts the queue after one request is completed. This patch implements this function in blk-mq core by introducing BLK_MQ_F_AUTO_RESTART, then we can remove stop/start queue related APIs and make 'stopped' state

[PATCH 3/6] block: don't call blk_mq_delay_run_hw_queue() in case of BLK_STS_RESOURCE

If .queue_rq() returns BLK_STS_RESOURCE, blk-mq will rerun the queue in the three situations: 1) if BLK_MQ_S_SCHED_RESTART is set - queue is rerun after one rq is completed, see blk_mq_sched_restart() which is run from blk_mq_free_request() 2) BLK_MQ_S_TAG_WAITING is set - queue is rerun after

[PATCH 0/6] blk-mq: cleanup start/stop queue

Hi, We have replaced most of start/stop queue via quiesce/unquiesce. And only the usage in case of handling BLK_STS_RESOURCE is kept. This patch moves this handling into blk-mq for xen-blkfront and virtio-blk, then we can avoid to let drivers touch the 'stopped' state, because allowing driver to

[PATCH 1/6] xen-blkfront: quiesce/unquiesce queue instead of start/stop queues

stopping queue may cause race and may not stop the queue really after the API returns, and we have improved quiescing interface and it really can block dispatching once it returns. So switch to quiesce/unquiece like what we did on other drivers (NVMe, NBD, mtip32xx, ...) The

[PATCH 2/6] SCSI: use blk_mq_run_hw_queues() in scsi_kick_queue()

Now SCSI won't stop queue at all, and not necessary to use blk_mq_start_hw_queues() to clear the state of 'stopped', so switch to blk_mq_run_hw_queues() instead. Cc: "James E.J. Bottomley" Cc: "Martin K. Petersen" Cc:

Re: [PATCH] block: note about cloned bios and bio_for_each_segment_all

On 07/14/2017 04:35 PM, Ming Lei wrote: > On Sat, Jul 15, 2017 at 4:54 AM, Liu Bo wrote: >> On Fri, Jul 14, 2017 at 08:22:31AM -0600, Jens Axboe wrote: >>> On 07/14/2017 07:47 AM, Ming Lei wrote: > @@ -156,6 +156,9 @@ static inline void *bio_data(struct bio *bio) >

Re: [PATCH] block: note about cloned bios and bio_for_each_segment_all

On Sat, Jul 15, 2017 at 4:54 AM, Liu Bo wrote: > On Fri, Jul 14, 2017 at 08:22:31AM -0600, Jens Axboe wrote: >> On 07/14/2017 07:47 AM, Ming Lei wrote: >> >> @@ -156,6 +156,9 @@ static inline void *bio_data(struct bio *bio) >> >> /* >> >> * drivers should _never_ use the

Re: [for-4.14 RFC PATCH 1/2] dm rq: avoid deadlock if dm-mq is stacked on old .request_fn device(s)

On Fri, Jul 14 2017 at 1:17pm -0400, Ewan D. Milne wrote: > On Fri, 2017-07-14 at 10:19 -0400, Mike Snitzer wrote: > > > > Do you see a benefit to extracting that portion of your WIP patch > > (removing the ->complete handler entirely)? > > > > Or leave well enough alone

Re: [PATCH] block: note about cloned bios and bio_for_each_segment_all

On Fri, Jul 14, 2017 at 08:22:31AM -0600, Jens Axboe wrote: > On 07/14/2017 07:47 AM, Ming Lei wrote: > >> @@ -156,6 +156,9 @@ static inline void *bio_data(struct bio *bio) > >> /* > >> * drivers should _never_ use the all version - the bio may have been > >> split > >> * before it got to

Re: [PATCH] block: note about cloned bios and bio_for_each_segment_all

On 07/14/2017 11:56 AM, Filipe Manana wrote: > > > On 07/14/2017 04:03 PM, David Sterba wrote: >> On Fri, Jul 14, 2017 at 09:47:30PM +0800, Ming Lei wrote: >>> On Fri, Jul 14, 2017 at 9:40 PM, David Sterba wrote: We've switched to cloned bios in btrfs and hit a nasty bug

Re: [PATCH] block: note about cloned bios and bio_for_each_segment_all

On 07/14/2017 04:03 PM, David Sterba wrote: > On Fri, Jul 14, 2017 at 09:47:30PM +0800, Ming Lei wrote: >> On Fri, Jul 14, 2017 at 9:40 PM, David Sterba wrote: >>> We've switched to cloned bios in btrfs and hit a nasty bug leading to >>> corruptions, when cloned bios are

Re: [PATCH blktests] sg: add regression test for patch scsi: sg: fix SG_DXFER_FROM_DEV transfers

On Thu, Jul 06, 2017 at 02:09:21PM +0200, Johannes Thumshirn wrote: > Add a regression test for the patch titled "scsi: sg: fix > SG_DXFER_FROM_DEV transfers" which reassembles the syscalls done by Nero > Burning ROM to discover CD and DVD burners. Fixed up a few things below and applied, thanks!

Re: [for-4.14 RFC PATCH 1/2] dm rq: avoid deadlock if dm-mq is stacked on old .request_fn device(s)

On Fri, 2017-07-14 at 10:19 -0400, Mike Snitzer wrote: > > Do you see a benefit to extracting that portion of your WIP patch > (removing the ->complete handler entirely)? > > Or leave well enough alone and just continue to disable dm-mq's ability > to stack on .request_fn paths? > > Given

Re: [PATCH blktests v2] tests: use nproc to get number of CPUs for fio jobs

On Fri, Jun 30, 2017 at 11:07:35AM +0200, Johannes Thumshirn wrote: > Use nproc to get number of CPUs for fio jobs and introduce > _run_fio_rand_io helper for parallel IO which we don't really care about > the details and just want some IO. Thanks, Johannes, applied with a fix below. >

Re: [PATCH] block: note about cloned bios and bio_for_each_segment_all

On Fri, Jul 14, 2017 at 09:47:30PM +0800, Ming Lei wrote: > On Fri, Jul 14, 2017 at 9:40 PM, David Sterba wrote: > > We've switched to cloned bios in btrfs and hit a nasty bug leading to > > corruptions, when cloned bios are iterated by bio_for_each_segment_all. > > No, you

Re: [PATCH] elevator: allow specifying elevator by config boot param for blk-mq devices

On 07/14/2017 12:40 AM, Johannes Thumshirn wrote: > On Thu, Jul 13, 2017 at 08:02:41AM -0600, Jens Axboe wrote: >> Because it sucks as an interface - there's no way to apply different >> settings to different devices, and using the kernel command line to >> control something like this is ugly. It

Re: [PATCH] block: note about cloned bios and bio_for_each_segment_all

On Fri, Jul 14, 2017 at 9:40 PM, David Sterba wrote: > We've switched to cloned bios in btrfs and hit a nasty bug leading to > corruptions, when cloned bios are iterated by bio_for_each_segment_all. No, you simply can't use bio_for_each_segment_all on cloned bio, and the reason

[PATCH] block: note about cloned bios and bio_for_each_segment_all

We've switched to cloned bios in btrfs and hit a nasty bug leading to corruptions, when cloned bios are iterated by bio_for_each_segment_all. Report and fix: https://patchwork.kernel.org/patch/9838535/ As a matter of precaution, we've added assertions to btrfs code to catch the bad usage

Re: linux-next scsi-mq hang in suspend-resume

On 14/07/17 15:44, Christoph Hellwig wrote: can you please report what hardware this is one (e.g. libata or real scsi, which driver), a kernel config and the actual command used to suspend the system (to ram, to disk?) so that I an try to reproduce it? The hardware I used to bisect the problem

Re: linux-next scsi-mq hang in suspend-resume

Tomi, can you please report what hardware this is one (e.g. libata or real scsi, which driver), a kernel config and the actual command used to suspend the system (to ram, to disk?) so that I an try to reproduce it?

Re: [PATCH blktests v2] tests: use nproc to get number of CPUs for fio jobs

Omar, ping? -- 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 21284 (AG Nürnberg) Key fingerprint = EC38

Re: [PATCH blktests] sg: add regression test for patch scsi: sg: fix SG_DXFER_FROM_DEV transfers

Omar, ping? -- 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 21284 (AG Nürnberg) Key fingerprint = EC38

[PATCH] blk-mq: don't leak preempt counter/q_usage_counter when allocating rq failed

From: Ming Lei When blk_mq_get_request() failed, preempt counter isn't released, and blk_mq_make_request() doesn't release the counter too. This patch fixes the issue, and makes sure that preempt counter is only held if rq is allocated successfully. The same policy is applied

[PATCH v2 3/3] md: raid1-10: move raid1/raid10 common code into raid1-10.c

No function change, just move 'struct resync_pages' and related helpers into raid1-10.c Signed-off-by: Ming Lei --- drivers/md/md.h | 53 --- drivers/md/raid1-10.c | 62 +++

[PATCH v2 2/3] md: raid1/raid10: initialize bvec table via bio_add_page()

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. Acked-by: Guoqing Jiang Signed-off-by: Ming Lei ---

[PATCH v2 1/3] md: remove 'idx' from 'struct resync_pages'

bio_add_page() won't fail for resync bio, and the page index for each bio is same, so remove it. More importantly the 'idx' of 'struct resync_pages' is initialized in mempool allocator function, the current way is wrong since mempool is only responsible for allocation, we can't use that for

[PATCH v2 0/3] md: three misc changes

This 1st patch fixes one issue introduced in the following two commits: Fixes: f0250618361d(md: raid10: don't use bio's vec table to manage resync pages) Fixes: 98d30c5812c3(md: raid1: don't use bio's vec table to manage resync pages) The 2nd one initializes bvec table of bio

Re: [for-4.14 RFC PATCH 1/2] dm rq: avoid deadlock if dm-mq is stacked on old .request_fn device(s)

The problem here is the following: blk_finish_request must always be called with the queue lock held, it even has an assert. Without blk-mq used by dm-rq, dm uses the block softirq to execute the completion, which means we always have a different execution context and can take the queue lock

Re: [for-4.14 RFC PATCH 0/2] dm rq: eliminate historic blk-mq and .request_fn queue stacking restrictions

Btw, we might want to expedite this to 4.13, a 4.13 now defaults to blk-mq for scsi, and this patch would make sure that dm keeps on just working with that switch.

Re: [PATCH] elevator: allow specifying elevator by config boot param for blk-mq devices

On Thu, Jul 13, 2017 at 08:02:41AM -0600, Jens Axboe wrote: > Because it sucks as an interface - there's no way to apply different > settings to different devices, and using the kernel command line to > control something like this is ugly. It never should have been done. > > The sysfs interface,