linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Coly Li <colyli@suse.de>
To: Vicente Bergas <vicencb@gmail.com>
Cc: linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-block@vger.kernel.org,
	Adrian Hunter <adrian.hunter@intel.com>,
	Ulf Hansson <ulf.hansson@linaro.org>
Subject: Re: [PATCH v3] mmc: core: don't set limits.discard_granularity as 0
Date: Fri, 2 Oct 2020 09:34:57 +0800	[thread overview]
Message-ID: <0eab931f-7f18-0074-3d8c-04ab0cf34e31@suse.de> (raw)
In-Reply-To: <b3cdb5fe-40df-41df-ae10-0b7be4dcd7a6@gmail.com>

On 2020/10/2 02:47, Vicente Bergas wrote:
> On Thursday, October 1, 2020 9:18:24 AM CEST, Coly Li 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>
>> 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);
>>  }
> 
> Tested on rk3399-gru-kevin with f2fs filesystem over the mmc driver, that
> is, the same setup that reproduced the issue.
> The kernel warning message is no longer reported.
> So,
> Tested-by: Vicente Bergas <vicencb@gmail.com>
> 

Hi Vicente,

Thank you very much!

Coly Li

      reply	other threads:[~2020-10-02  1:35 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
2020-10-01 18:47 ` Vicente Bergas
2020-10-02  1:34   ` Coly Li [this message]

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=0eab931f-7f18-0074-3d8c-04ab0cf34e31@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).