public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mtd: nand: check status before reporting timeout
@ 2016-03-05  1:19 Brian Norris
  2016-03-07 21:51 ` Brian Norris
  0 siblings, 1 reply; 2+ messages in thread
From: Brian Norris @ 2016-03-05  1:19 UTC (permalink / raw)
  To: linux-mtd
  Cc: linux-kernel, Brian Norris, Boris Brezillon, Richard Weinberger,
	Harvey Hunt, Alex Smith, Niklas Cassel, Alex Smith

In commit b70af9bef49b ("mtd: nand: increase ready wait timeout and
report timeouts"), we increased the likelihood of scheduling during
nand_wait(). This makes us more likely to hit the time_before(...)
condition, since a lot of time may pass before we get scheduled again.

Now, the loop was already buggy, since we don't check if the NAND is
ready after exiting the loop; we simply print out a timeout warning. Fix
this by doing a final status check before printing a timeout message.

This isn't actually a critical bug, since the only effect is a false
warning print. But too many prints never hurt anyone, did they? :)

Side note: perhaps I'm not smart enough, but I'm not sure what the best
policy is for this kind of loop; do we busy loop (i.e., no
cond_resched()) to keep the lowest I/O latency (it's not great if the
resched is delaying Richard's system ~400ms)? Or do we allow
rescheduling, to play nice with the rest of the system (since some
operations can take quite a while)?

Reported-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Harvey Hunt <harvey.hunt@imgtec.com>
---
 drivers/mtd/nand/nand_base.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index f2c8ff398d6c..596a9b0503da 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -566,8 +566,8 @@ void nand_wait_ready(struct mtd_info *mtd)
 		cond_resched();
 	} while (time_before(jiffies, timeo));
 
-	pr_warn_ratelimited(
-		"timeout while waiting for chip to become ready\n");
+	if (!chip->dev_ready(mtd))
+		pr_warn_ratelimited("timeout while waiting for chip to become ready\n");
 out:
 	led_trigger_event(nand_led_trigger, LED_OFF);
 }
-- 
2.7.0.rc3.207.g0ac5344

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] mtd: nand: check status before reporting timeout
  2016-03-05  1:19 [PATCH] mtd: nand: check status before reporting timeout Brian Norris
@ 2016-03-07 21:51 ` Brian Norris
  0 siblings, 0 replies; 2+ messages in thread
From: Brian Norris @ 2016-03-07 21:51 UTC (permalink / raw)
  To: linux-mtd
  Cc: linux-kernel, Boris Brezillon, Richard Weinberger, Harvey Hunt,
	Alex Smith, Niklas Cassel, Alex Smith

On Fri, Mar 04, 2016 at 05:19:23PM -0800, Brian Norris wrote:
> In commit b70af9bef49b ("mtd: nand: increase ready wait timeout and
> report timeouts"), we increased the likelihood of scheduling during
> nand_wait(). This makes us more likely to hit the time_before(...)
> condition, since a lot of time may pass before we get scheduled again.
> 
> Now, the loop was already buggy, since we don't check if the NAND is
> ready after exiting the loop; we simply print out a timeout warning. Fix
> this by doing a final status check before printing a timeout message.
> 
> This isn't actually a critical bug, since the only effect is a false
> warning print. But too many prints never hurt anyone, did they? :)
> 
> Side note: perhaps I'm not smart enough, but I'm not sure what the best
> policy is for this kind of loop; do we busy loop (i.e., no
> cond_resched()) to keep the lowest I/O latency (it's not great if the
> resched is delaying Richard's system ~400ms)? Or do we allow
> rescheduling, to play nice with the rest of the system (since some
> operations can take quite a while)?
> 
> Reported-by: Richard Weinberger <richard@nod.at>
> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> Reviewed-by: Richard Weinberger <richard@nod.at>
> Reviewed-by: Harvey Hunt <harvey.hunt@imgtec.com>

Applied

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-03-07 21:51 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-05  1:19 [PATCH] mtd: nand: check status before reporting timeout Brian Norris
2016-03-07 21:51 ` Brian Norris

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox