linux-kernel - Re: [PATCH v2] mtd: rawnand: Increment IFC_TIMEOUT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZVJJAReXiEVc35HZ@smile.fi.intel.com>
Date:   Mon, 13 Nov 2023 18:04:17 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Ronald Monthero <debug.penguin32@...il.com>
Cc:     richard@....at, vigneshr@...com, heiko@...ech.de,
        martin.blumenstingl@...glemail.com, paul@...pouillou.net,
        robh@...nel.org, u.kleine-koenig@...gutronix.de,
        AVKrasnov@...rdevices.ru, r.czerwinski@...gutronix.de,
        jaimeliao.tw@...il.com, linux-mtd@...ts.infradead.org,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Miquel Raynal <miquel.raynal@...tlin.com>
Subject: Re: [PATCH v2] mtd: rawnand: Increment IFC_TIMEOUT_MSECS for nand
 controller response

You are too quick with v2, below my comments (new and old).

On Tue, Nov 14, 2023 at 01:53:51AM +1000, Ronald Monthero wrote:
> Under heavy load it is likely that the controller is done
> with its own task but the thread unlocking the wait is not
> scheduled in time. Increasing IFC_TIMEOUT_MSECS allows the
> controller to respond within allowable timeslice of 1 sec

Missing period at the end?

> fsl,ifc-nand 7e800000.nand: Controller is not responding

> main/smp_fsm.c:1884 <inrcu: rcu_preempt detected stalls on CPUs/tasks:
> rcu:    Tasks blocked on level-0 rcu_node (CPUs 0-1): P116/2:b..l
>         (detected by 1, t=2102 jiffies, g=7729, q=754)
> task:irq/31-arm-irq1 state:D stack: 0 pid: 116 ppid: 2 flags:0x00000000
> [<8064b97f>] (__schedule) from [<8064bb01>] (schedule+0x8d/0xc2)
> [<8064bb01>] (schedule) from [<8064dacd>]
> [<8064dacd>] (rt_mutex_slowlock_block.constprop.0) from [<8064db57>]
> [<8064db57>] (__rt_mutex_slowlock.constprop.0) from [<8064dbf7>]
> [<8064dbf7>] (rt_mutex_slowlock.constprop.0) from [<804b2047>]

At least above 9 lines are not important and may be removed.

> [<804b2047>] (nand_get_device) from [<804b5335>] (nand_write_oob+0x1b/0x4a)
> [<804b5335>] (nand_write_oob) from [<804a3585>] (mtd_write+0x41/0x5c)
> [<804a3585>] (mtd_write) from [<804c1d47>] (ubi_io_write+0x17f/0x22c)
> [<804c1d47>] (ubi_io_write) from [<804c047b>] (ubi_eba_write_leb+0x5b/0x1d0)

...

> -#define IFC_TIMEOUT_MSECS	500  /* Maximum number of mSecs to wait
> +#define IFC_TIMEOUT_MSECS	1000  /* Maximum number of mSecs to wait
>  					for IFC NAND Machine	*/

While at it, you may improve the comment, e.g.,

  "Maximum timeout to wait for IPC NAND Machine"

-- 
With Best Regards,
Andy Shevchenko