diff mbox series

[v3] mmc: core: don't set limits.discard_granularity as 0

Message ID 20201001071824.24995-1-colyli@suse.de
State Superseded
Headers show
Series [v3] mmc: core: don't set limits.discard_granularity as 0 | expand

Commit Message

Coly Li Oct. 1, 2020, 7:18 a.m. UTC
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(-)

Comments

Vicente Bergas Oct. 1, 2020, 8:38 a.m. UTC | #1
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?
Regards,
  Vicente.

> 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
>
Adrian Hunter Oct. 1, 2020, 9:06 a.m. UTC | #2
On 1/10/20 11:38 am, 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?

Very low I would hope, but that is no reason not to have backups :-)

> Regards,
>   Vicente.
> 
>> 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
>>
Vicente Bergas Oct. 1, 2020, 9:27 a.m. UTC | #3
On Thu, Oct 1, 2020 at 11:07 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
>
> On 1/10/20 11:38 am, 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?
>
> Very low I would hope, but that is no reason not to have backups :-)

I do have backup, it is for the hassle of reinstalling the OS and
restoring the backup.
I'll test it later, maybe today.

> > Regards,
> >   Vicente.
> >
> >> 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 */

Just out of curiosity, wouldn't it be more performant something like:
q->limits.discard_granularity = minimum(card->pref_erase, max_discard) << 9;
or is just that SECTOR_SIZE is a number guaranteed to work?

> >>         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
> >>
>
Coly Li Oct. 1, 2020, 10 a.m. UTC | #4
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
>>
Coly Li Oct. 1, 2020, 10:06 a.m. UTC | #5
On 2020/10/1 17:27, Vicente Bergas wrote:
> On Thu, Oct 1, 2020 at 11:07 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
>>
>> On 1/10/20 11:38 am, 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?
>>
>> Very low I would hope, but that is no reason not to have backups :-)
> 
> I do have backup, it is for the hassle of reinstalling the OS and
> restoring the backup.
> I'll test it later, maybe today.
> 
>>> Regards,
>>>   Vicente.
>>>
>>>> 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 */
> 
> Just out of curiosity, wouldn't it be more performant something like:
> q->limits.discard_granularity = minimum(card->pref_erase, max_discard) << 9;
> or is just that SECTOR_SIZE is a number guaranteed to work?
> 

The discard_granularity is a hint for the minimal acceptable length of
the discard request. The discard request might be accepted by device
when the discard request covers a discard_granularity range. The
discard_granularity rage is the minimum available discard request
length, it is a LBA range which starts on discard_granularity aligned
LBA, and length is discard_granularity.

Therefore setting discard_granularity to SECTOR_SIZE won't hurt discard
performance, the discard bio split does not depend on it. It is a hint
for a minimal acceptable length of discard request.

Coly Li
Adrian Hunter Oct. 1, 2020, 10:07 a.m. UTC | #6
On 1/10/20 12:27 pm, Vicente Bergas wrote:
> On Thu, Oct 1, 2020 at 11:07 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
>>
>> On 1/10/20 11:38 am, 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?
>>
>> Very low I would hope, but that is no reason not to have backups :-)
> 
> I do have backup, it is for the hassle of reinstalling the OS and
> restoring the backup.
> I'll test it later, maybe today.
> 
>>> Regards,
>>>   Vicente.
>>>
>>>> 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 */
> 
> Just out of curiosity, wouldn't it be more performant something like:
> q->limits.discard_granularity = minimum(card->pref_erase, max_discard) << 9;
> or is just that SECTOR_SIZE is a number guaranteed to work?

SECTOR_SIZE is guaranteed to work.  It is preferable, but not necessary, to
align to the devices internal erase block size.

> 
>>>>         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
>>>>
>>
Vicente Bergas Oct. 1, 2020, 6:47 p.m. UTC | #7
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>
Coly Li Oct. 2, 2020, 1:34 a.m. UTC | #8
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
diff mbox series

Patch

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);
 }