Re: [PATCH 0/4] blk-throttle: fix a few issues

On 05/17/2017 02:07 PM, Shaohua Li wrote: > Hi, > > The patchset fix a few issues for io.low limit. The title of the patches > explain the issues pretty well. Looks good to me, added for 4.12-rc3. -- Jens Axboe

Re: [PATCH BUGFIX] block, bfq: access and cache blkg data only when safe

> Il giorno 19 mag 2017, alle ore 16:37, Jens Axboe ha > scritto: > > On 05/19/2017 02:39 AM, Paolo Valente wrote: >> @@ -692,8 +725,7 @@ void bfq_pd_offline(struct blkg_policy_data *pd) >> /* >> * The idle tree may still contain bfq_queues belonging

Re: [dm-devel] [PATCH 08/15] dm mpath: merge do_end_io_bio into multipath_end_io_bio

On Thu, 2017-05-18 at 15:18 +0200, Christoph Hellwig wrote: > This simplifies the code and especially the error passing a bit and > will help with the next patch. > > Signed-off-by: Christoph Hellwig > --- >  drivers/md/dm-mpath.c | 42 - > - >

Re: [PATCH v3 0/3] nvme: fix hang in path of removing disk

Thanks Ming, I'll add the three patches to the nvme-4.12 queue, assuming Jens is okay with us queueing up the block path to remove blk_mq_abort_requeue_list.

Re: [PATCH blktests v2 3/3] sg/001: add regression test for syzcaller generated GPF in sg_read path

On Fri, May 19, 2017 at 03:55:31PM +0200, Johannes Thumshirn wrote: > Add a regression test for commit 48ae8484e9fc ("scsi: sg: don't return > bogus Sg_requests"). This is a general protection fault triggered by > syzcaller via issuing bogus read(2)s on the /dev/sg devices. > > Signed-off-by:

[PATCH v3 1/3] nvme: use blk_mq_start_hw_queues() in nvme_kill_queues()

Inside nvme_kill_queues(), we have to start hw queues for draining requests in sw queues, .dispatch list and requeue list, so use blk_mq_start_hw_queues() instead of blk_mq_start_stopped_hw_queues() which only run queues if queues are stopped, but the queues may have been started already, for

[PATCH v3 2/3] nvme: avoid to use blk_mq_abort_requeue_list()

NVMe may add request into requeue list simply and not kick off the requeue if hw queues are stopped. Then blk_mq_abort_requeue_list() is called in both nvme_kill_queues() and nvme_ns_remove() for dealing with this issue. Unfortunately blk_mq_abort_requeue_list() is absolutely a race maker, for

Re: [PATCH v2 1/3] nvme: use blk_mq_start_hw_queues() in nvme_kill_queues()

On Mon, May 22, 2017 at 02:51:40PM +0200, Christoph Hellwig wrote: > On Mon, May 22, 2017 at 09:35:58AM +0800, Ming Lei wrote: > > In theory, it should be OK to stop and start queues again before the final > > removal, so how about the following: > > > > * Note: We must make sure to

Re: [PATCH v2 1/3] nvme: use blk_mq_start_hw_queues() in nvme_kill_queues()

On Mon, May 22, 2017 at 09:35:58AM +0800, Ming Lei wrote: > In theory, it should be OK to stop and start queues again before the final > removal, so how about the following: > >* Note: We must make sure to not put the queues into being > stopped >forever from now

Re: [PATCH 0/6] More MMC block core refactorings

On Mon, May 22, 2017 at 12:44:14PM +, Avri Altman wrote: > Those debugfs entries are there for ages, and there are some user-space > utilities, > e.g. for benchmarking etc. that count on it being there, > as the key identification criteria if a mmc device is present. debugfs is an

RE: [PATCH 0/6] More MMC block core refactorings

> -Original Message- > From: Ulf Hansson [mailto:ulf.hans...@linaro.org] > Sent: Monday, May 22, 2017 3:05 PM > To: Linus Walleij > Cc: linux-...@vger.kernel.org; Adrian Hunter ; > linux-block@vger.kernel.org; Jens Axboe

Re: [PATCH 0/6] More MMC block core refactorings

On 19 May 2017 at 15:37, Linus Walleij wrote: > This series builds on top of the previous series that created > custom DRV_OP requests for ioctl() operations in MMC. > > The first patch is a suggestion from Christoph, the second > builds infrastructure for issuing more,

Re: [PATCH] blk-mq: provide a default .bio_merge

On Sat, May 20, 2017 at 11:30:59PM -0700, Christoph Hellwig wrote: > On Sat, May 13, 2017 at 12:20:54AM +0800, Ming Lei wrote: > > Before blk-mq is introduced, I/O is merged before putting into > > plug queue, but blk-mq changed the order and makes merging > > basically impossible until

Re: [PATCH 02/18] bsg: Check private request size before attaching to a queue

On Sun, May 21, 2017 at 02:33:05PM +, Bart Van Assche wrote: > Thanks for the review comments. The cover letter should have made it to at > least the linux-scsi mailing list since it shows up in at least one archive of > that mailing list:

Re: [PATCH v2 3/3] blk-mq: remove blk_mq_abort_requeue_list()

On 05/20/2017 05:56 AM, Ming Lei wrote: > No one uses it any more, so remove it. > > Signed-off-by: Ming Lei > --- Looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de

Re: [PATCH v2 2/3] nvme: avoid to use blk_mq_abort_requeue_list()

On 05/20/2017 07:34 AM, Ming Lei wrote: > On Sat, May 20, 2017 at 11:56:04AM +0800, Ming Lei wrote: >> NVMe may add request into requeue list simply and not kick off the >> requeue if hw queues are stopped. Then blk_mq_abort_requeue_list() >> is called in both nvme_kill_queues() and

Re: [PATCH 5/6] mmc: debugfs: Move card status retrieveal into the block layer

On 19 May 2017 at 15:37, Linus Walleij wrote: > The debugfs file "status" (in e.g. /debug/mmc3/mmc3:0001) is > only available if and only if the card used is an (e)MMC or > SD card, not for SDIO, as can be seen from this guard in > mmc_add_card_debugfs(); > > if

Re: [PATCH v2 1/1] partitions/msdos: FreeBSD UFS2 file systems are not recognized

Looks good, Reviewed-by: Christoph Hellwig