Re: [PATCH 1/2 v6] mmc: block: Convert RPMB to a character device

On 2017/9/28 3:45, Linus Walleij wrote: On Wed, Sep 27, 2017 at 1:35 PM, Adrian Hunter wrote: BUG when removing, fixed by reverting this patch. [ 346.548512] mmc1: card 0001 removed [ 346.552782] BUG: unable to handle kernel NULL pointer dereference at

Re: [PATCH] blk-throttle: fix possible io stall when doing upgrade

Hi Shahua, On 17/9/28 05:38, Shaohua Li wrote: > On Tue, Sep 26, 2017 at 11:16:05AM +0800, Joseph Qi wrote: >> >> >> On 17/9/26 10:48, Shaohua Li wrote: >>> On Tue, Sep 26, 2017 at 09:06:57AM +0800, Joseph Qi wrote: Hi Shaohua, On 17/9/26 01:22, Shaohua Li wrote: > On Mon, Sep

Re: [PATCH] badblocks: fix wrong return value in badblocks_set if badblocks are disabled

On 09/28/2017 06:13 AM, Liu Bo wrote: MD's rdev_set_badblocks() expects that badblocks_set() returns 1 if badblocks are disabled, otherwise, rdev_set_badblocks() will record superblock changes and return success in that case and md will fail to report an IO error which it should. This bug has

Re: [PATCH 1/1] bcache: use llist_for_each_entry_safe() in __closure_wake_up()

On 2017/9/28 上午4:52, Jens Axboe wrote: > On 09/27/2017 10:48 PM, Michael Lyle wrote: >> Jens-- >> >> I think it's a race condition-- the individual closures remain valid. >> It's just that the list element has different meanings-- it's either a >> list actively being used to wake, or a linkage on

[PATCH] badblocks: fix wrong return value in badblocks_set if badblocks are disabled

MD's rdev_set_badblocks() expects that badblocks_set() returns 1 if badblocks are disabled, otherwise, rdev_set_badblocks() will record superblock changes and return success in that case and md will fail to report an IO error which it should. This bug has existed since badblocks were introduced

Re: [PATCH] blk-throttle: fix possible io stall when doing upgrade

On Tue, Sep 26, 2017 at 11:16:05AM +0800, Joseph Qi wrote: > > > On 17/9/26 10:48, Shaohua Li wrote: > > On Tue, Sep 26, 2017 at 09:06:57AM +0800, Joseph Qi wrote: > >> Hi Shaohua, > >> > >> On 17/9/26 01:22, Shaohua Li wrote: > >>> On Mon, Sep 25, 2017 at 06:46:42PM +0800, Joseph Qi wrote: >

Re: [PATCH 1/1] bcache: use llist_for_each_entry_safe() in __closure_wake_up()

On 09/27/2017 10:48 PM, Michael Lyle wrote: > Jens-- > > I think it's a race condition-- the individual closures remain valid. > It's just that the list element has different meanings-- it's either a > list actively being used to wake, or a linkage on one of several lists > that is being used to

Re: [PATCH 1/1] bcache: use llist_for_each_entry_safe() in __closure_wake_up()

Jens-- I think it's a race condition-- the individual closures remain valid. It's just that the list element has different meanings-- it's either a list actively being used to wake, or a linkage on one of several lists that is being used to await wake. If a closure goes back to wait very quickly

Re: [PATCH 1/1] bcache: use llist_for_each_entry_safe() in __closure_wake_up()

On 09/26/2017 11:54 AM, Coly Li wrote: > Commit 09b3efec ("bcache: Don't reinvent the wheel but use existing llist > API") replaces the following while loop by llist_for_each_entry(), If it's fixing a specific commit, please add a proper Fixes: sha ("title") line to your patch. That way

Re: [PATCH 1/1] bcache: use llist_for_each_entry_safe() in __closure_wake_up()

On 09/27/2017 09:16 PM, Coly Li wrote: > Hi Jens, > > Could you please take a look on this patch? It will be helpful if we can > have it in 4.14, then we can fix a bug introduced in 4.14-rc1. > > This patch is reported by Michael Lyle, reviewed by Byungchul Park, and > finally verified by

Re: [PATCH V9 09/15] mmc: core: Add parameter use_blk_mq

On Wed, Sep 27, 2017 at 2:02 PM, Adrian Hunter wrote: > On 27/09/17 02:42, Linus Walleij wrote: >> On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter >> wrote: >> >>> Until mmc has blk-mq support fully implemented and tested, add a >>> parameter

Re: [PATCH 1/2 v6] mmc: block: Convert RPMB to a character device

On Wed, Sep 27, 2017 at 1:35 PM, Adrian Hunter wrote: > > BUG when removing, fixed by reverting this patch. > > [ 346.548512] mmc1: card 0001 removed > [ 346.552782] BUG: unable to handle kernel NULL pointer dereference at > 0070 How did you achieve this?

Re: [GIT PULL] Block fixes for 4.14-rc2

On 09/27/2017 07:36 PM, Linus Torvalds wrote: > On Wed, Sep 27, 2017 at 5:41 AM, Jens Axboe wrote: >> >> So I reworked the series, to include three prep patches that end up >> killing off free_more_memory(). This means that we don't have to do the >> 1024 -> 0 change in there. On

Re: [PATCH 1/1] bcache: use llist_for_each_entry_safe() in __closure_wake_up()

Hi Jens, Could you please take a look on this patch? It will be helpful if we can have it in 4.14, then we can fix a bug introduced in 4.14-rc1. This patch is reported by Michael Lyle, reviewed by Byungchul Park, and finally verified by Michael Lyle after I posted the patch. Many thanks in

Re: [GIT PULL] Block fixes for 4.14-rc2

On Wed, Sep 27, 2017 at 5:41 AM, Jens Axboe wrote: > > So I reworked the series, to include three prep patches that end up > killing off free_more_memory(). This means that we don't have to do the > 1024 -> 0 change in there. On top of that, I added a separate bit to > manage

RE: [PATCH V9 09/15] mmc: core: Add parameter use_blk_mq

> -Original Message- > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- > ow...@vger.kernel.org] On Behalf Of Linus Walleij > Sent: Wednesday, September 27, 2017 2:42 AM > To: Adrian Hunter > Cc: Ulf Hansson ; linux-mmc

Re: [GIT PULL] Block fixes for 4.14-rc2

Travel stable again, catching up. Chris did a great job explaining what our issues were, so thanks for that. On 09/26/2017 12:21 AM, Linus Torvalds wrote: > On Mon, Sep 25, 2017 at 2:17 PM, Chris Mason wrote: >> >> My understanding is that for order-0 page allocations and >>

Re: [PATCH V9 09/15] mmc: core: Add parameter use_blk_mq

On 27/09/17 02:42, Linus Walleij wrote: > On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter > wrote: > >> Until mmc has blk-mq support fully implemented and tested, add a >> parameter use_blk_mq, default to false unless config option MMC_MQ_DEFAULT >> is selected. >> >>

Re: [PATCH 1/2 v6] mmc: block: Convert RPMB to a character device

BUG when removing, fixed by reverting this patch. [ 346.548512] mmc1: card 0001 removed [ 346.552782] BUG: unable to handle kernel NULL pointer dereference at 0070 [ 346.561539] IP: kernfs_find_ns+0xe/0xc0 [ 346.565822] PGD 179dc5067 P4D 179dc5067 PUD 171106067 PMD 0 [

Re: [PATCH v4 1/7] md: Make md resync and reshape threads freezable

On Wed, Sep 27, 2017 at 03:12:47AM +, Bart Van Assche wrote: > On Tue, 2017-09-26 at 22:59 +0800, Ming Lei wrote: > > On Tue, Sep 26, 2017 at 02:42:07PM +, Bart Van Assche wrote: > > > On Tue, 2017-09-26 at 19:17 +0800, Ming Lei wrote: > > > > Just test this patch a bit and the following

Re: [PATCH V6 6/6] SCSI: set block queue at preempt only when SCSI device is put into quiesce

On Wed, 2017-09-27 at 13:48 +0800, Ming Lei wrote: > @@ -2928,12 +2929,28 @@ scsi_device_quiesce(struct scsi_device *sdev) > { > int err; > > + /* > + * Simply quiesing SCSI device isn't safe, it is easy > + * to use up requests because all these allocated requests > +

Re: [PATCH V6 0/6] block/scsi: safe SCSI quiescing

On Wed, Sep 27, 2017 at 04:27:51PM +0800, Ming Lei wrote: > On Wed, Sep 27, 2017 at 09:57:37AM +0200, Martin Steigerwald wrote: > > Hi Ming. > > > > Ming Lei - 27.09.17, 13:48: > > > Hi, > > > > > > The current SCSI quiesce isn't safe and easy to trigger I/O deadlock. > > > > > > Once SCSI

Re: [PATCH V6 0/6] block/scsi: safe SCSI quiescing

On Wed, Sep 27, 2017 at 09:57:37AM +0200, Martin Steigerwald wrote: > Hi Ming. > > Ming Lei - 27.09.17, 13:48: > > Hi, > > > > The current SCSI quiesce isn't safe and easy to trigger I/O deadlock. > > > > Once SCSI device is put into QUIESCE, no new request except for > > RQF_PREEMPT can be

Re: [PATCH 4/5] bcache: writeback: collapse contiguous IO better

I just fixed the problem you pointed out, and ran a test where I did sync;fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=8k --iodepth=256 --size=25G --readwrite=randwrite --ramp_time=4 to generate a lot of 8k extents. After letting things quiet

Re: [PATCH 4/5] bcache: writeback: collapse contiguous IO better

Tang-- This is a first step towards further stuff I want to do-- 1. I want to allow blk_plug-- but to do that, a request needs to know there are subsequent contiguous requests after it when issuing the write. The new structure allows that. 2. I want to allow tuning to issue multiple requests

Re: [PATCH 4/5] bcache: writeback: collapse contiguous IO better

From: Tang Junhui Hello Mike: For the second question, I thinks this modification is somewhat complex, cannot we do something simple to resolve it? I remember there were some patches trying to avoid too small writeback rate, Coly, is there any progress now? ---

Re: [PATCH 1/5] bcache: don't write back data if reading it failed

Ah-- re #1 -- I was investigating earlier why not as much was combined as I thought should be when idle. This is surely a factor. Thanks for the catch-- KEY_OFFSET is correct. I will fix and retest. (Under heavy load, the correct thing still happens, but not under light or intermediate load0.

Re: [PATCH 1/5] bcache: don't write back data if reading it failed

From: Tang Junhui Hello Lyle: Two questions: 1) In keys_contiguous(), you judge I/O contiguous in cache device, but not in backing device. I think you should judge it by backing device (remove PTR_CACHE() and use KEY_OFFSET() instead of PTR_OFFSET()?). 2) I did not see

Re: [PATCH V6 2/6] block: tracking request allocation with q_usage_counter

On 09/27/2017 07:48 AM, Ming Lei wrote: > This usage is basically same with blk-mq, so that we can > support to freeze legacy queue easily. > > Also 'wake_up_all(>mq_freeze_wq)' has to be moved > into blk_set_queue_dying() since both legacy and blk-mq > may wait on the wait queue of