On 2020/9/28 11:15, Coly Li wrote:

On 2020/9/28 04:29, Vicente Bergas wrote:

quoted

Hi,
since recently the rk3399-gru-kevin is reporting the trace below.
The issue has been uncovered by
 b35fd7422c2f8e04496f5a770bd4e1a205414b3f
 block: check queue's limits.discard_granularity in
__blkdev_issue_discard()

Hi Vicente,

Thanks for the information. It seems the device with f2fs declares to
support DISCARD but don't initialize discard_granularity for its queue.

Can I know which block driver is under f2fs ?

Maybe it is the mmc driver. A zero value discard_granularity is from the
following commit:

commit e056a1b5b67b4e4bfad00bf143ab14f634777705
Author: Adrian Hunter [off-list ref]
Date:   Tue Jun 28 17:16:02 2011 +0300

    mmc: queue: let host controllers specify maximum discard timeout

    Some host controllers will not operate without a hardware
    timeout that is limited in value.  However large discards
    require large timeouts, so there needs to be a way to
    specify the maximum discard size.

    A host controller driver may now specify the maximum discard
    timeout possible so that max_discard_sectors can be calculated.

    However, for eMMC when the High Capacity Erase Group Size
    is not in use, the timeout calculation depends on clock
    rate which may change.  For that case Preferred Erase Size
    is used instead.

    Signed-off-by: Adrian Hunter [off-list ref]
    Signed-off-by: Chris Ball [off-list ref]


Hi Adrian and Chris,

I am not familiar with mmc driver, therefore I won't provide a quick fix
like this (which might probably wrong),

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


It is improper for a device driver to declare to support DISCARD but set
queue's discard_granularity as 0.

Could you please to take a look for mmc_queue_setup_discard() ?

Thanks in advance.

Coly Li

quoted

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 ]---
mmcblk1p2: Error: discard_granularity is 0.
mmcblk1p2: Error: discard_granularity is 0.
<last message repeated multiple times>