All of lore.kernel.org
 help / color / mirror / Atom feed
From: Coly Li <colyli@suse.de>
To: Vicente Bergas <vicencb@gmail.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	linux-mmc@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-block@vger.kernel.org, Ulf Hansson <ulf.hansson@linaro.org>
Subject: Re: [PATCH v3] mmc: core: don't set limits.discard_granularity as 0
Date: Thu, 1 Oct 2020 18:00:04 +0800	[thread overview]
Message-ID: <443b9ed1-b075-d86d-e734-c9ec78653842@suse.de> (raw)
In-Reply-To: <CAAMcf8Ao8Go7GdB2XFXAHsWrcxb0VqtDRpHReOGTsjegq2XP0Q@mail.gmail.com>

On 2020/10/1 16:38, Vicente Bergas wrote:
> On Thu, Oct 1, 2020 at 9:18 AM Coly Li <colyli@suse.de> wrote:
>>
>> In mmc_queue_setup_discard() the mmc driver queue's discard_granularity
>> might be set as 0 (when card->pref_erase > max_discard) while the mmc
>> device still declares to support discard operation. This is buggy and
>> triggered the following kernel warning message,
>>
>> WARNING: CPU: 0 PID: 135 at __blkdev_issue_discard+0x200/0x294
>> CPU: 0 PID: 135 Comm: f2fs_discard-17 Not tainted 5.9.0-rc6 #1
>> Hardware name: Google Kevin (DT)
>> pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--)
>> pc : __blkdev_issue_discard+0x200/0x294
>> lr : __blkdev_issue_discard+0x54/0x294
>> sp : ffff800011dd3b10
>> x29: ffff800011dd3b10 x28: 0000000000000000 x27: ffff800011dd3cc4 x26: ffff800011dd3e18 x25: 000000000004e69b x24: 0000000000000c40 x23: ffff0000f1deaaf0 x22: ffff0000f2849200 x21: 00000000002734d8 x20: 0000000000000008 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000394 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 00000000000008b0 x9 : ffff800011dd3cb0 x8 : 000000000004e69b x7 : 0000000000000000 x6 : ffff0000f1926400 x5 : ffff0000f1940800 x4 : 0000000000000000 x3 : 0000000000000c40 x2 : 0000000000000008 x1 : 00000000002734d8 x0 : 0000000000000000 Call trace:
>> __blkdev_issue_discard+0x200/0x294
>> __submit_discard_cmd+0x128/0x374
>> __issue_discard_cmd_orderly+0x188/0x244
>> __issue_discard_cmd+0x2e8/0x33c
>> issue_discard_thread+0xe8/0x2f0
>> kthread+0x11c/0x120
>> ret_from_fork+0x10/0x1c
>> ---[ end trace e4c8023d33dfe77a ]---
>>
>> This patch fixes the issue by setting discard_granularity as SECTOR_SIZE
>> instead of 0 when (card->pref_erase > max_discard) is true. Now no more
>> complain from __blkdev_issue_discard() for the improper value of discard
>> granularity.
>>
>> This issue is exposed after commit b35fd7422c2f ("block: check queue's
>> limits.discard_granularity in __blkdev_issue_discard()"), a "Fixes:" tag
>> is also added for the commit to make sure people won't miss this patch
>> after applying the change of __blkdev_issue_discard().
>>
>> Fixes: e056a1b5b67b ("mmc: queue: let host controllers specify maximum discard timeout")
>> Fixes: b35fd7422c2f ("block: check queue's limits.discard_granularity in __blkdev_issue_discard()").
>> Reported-by: Vicente Bergas <vicencb@gmail.com>
> 
> Hi Coly, Adrian,
> would you like me to reply with a tested-by?
> before testing it: what are the chances of losing data?


Hi Vicente,

Please do :-)

I will wait for your reply and post a v4 version.

Thanks.

Coly Li


>> Signed-off-by: Coly Li <colyli@suse.de>
>> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
>> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>> ---
>> Changelog,
>> v3, add Fixes tag for both commits.
>> v2, change commit id of the Fixes tag.
>> v1, initial version.
>>
>>  drivers/mmc/core/queue.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
>> index 6c022ef0f84d..350d0cc4ee62 100644
>> --- a/drivers/mmc/core/queue.c
>> +++ b/drivers/mmc/core/queue.c
>> @@ -190,7 +190,7 @@ static void mmc_queue_setup_discard(struct request_queue *q,
>>         q->limits.discard_granularity = card->pref_erase << 9;
>>         /* granularity must not be greater than max. discard */
>>         if (card->pref_erase > max_discard)
>> -               q->limits.discard_granularity = 0;
>> +               q->limits.discard_granularity = SECTOR_SIZE;
>>         if (mmc_can_secure_erase_trim(card))
>>                 blk_queue_flag_set(QUEUE_FLAG_SECERASE, q);
>>  }
>> --
>> 2.26.2
>>


  parent reply	other threads:[~2020-10-01 10:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01  7:18 [PATCH v3] mmc: core: don't set limits.discard_granularity as 0 Coly Li
2020-10-01  8:38 ` Vicente Bergas
2020-10-01  9:06   ` Adrian Hunter
2020-10-01  9:27     ` Vicente Bergas
2020-10-01 10:06       ` Coly Li
2020-10-01 10:07       ` Adrian Hunter
2020-10-01 10:00   ` Coly Li [this message]
2020-10-01 18:47 ` Vicente Bergas
2020-10-02  1:34   ` Coly Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=443b9ed1-b075-d86d-e734-c9ec78653842@suse.de \
    --to=colyli@suse.de \
    --cc=adrian.hunter@intel.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=vicencb@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.