| Message ID | 1457140763-67571-1-git-send-email-computersforpeace@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
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
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); }
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(-)