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]
Date:	Mon, 17 Aug 2015 00:18:09 +0200
From:	Robert Jarzmik <robert.jarzmik@...e.fr>
To:	Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
Cc:	Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Brian Norris <computersforpeace@...il.com>,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Antoine Tenart <antoine.tenart@...e-electrons.com>
Subject: Re: [PATCH] mtd: nand: pxa3xx-nand: fix random command timeouts

Ezequiel Garcia <ezequiel@...guardiasur.com.ar> writes:

> On 12 Aug 06:22 PM, Robert Jarzmik wrote:
>
> This fix looks correct. Thanks!
>
> Couple questions:
>
> 1. In which platform are you seeing this bug?
zylonite with a pxa310 (ie. internal stacked NAND).

> 2. Is this a regression? (i.e. should we queue it for -stable?)
No, it's been there for ages I think.

> Also, one might question why we can't just write NDSR right after it's read,
> before we wake the IRQ thread or start DMA. It appears this is
> a requirement of BCH, as per the comment in drain_fifo.
For irq thread that won't make any difference, the irq handler will finish first
and clear the bits anyway. For DMA it's better.

And more generaly speaking, I like it better, to clear it once read.

> It would be nice to put a comment explaining why we clear NDSR only
> before the check to WRCMDREQ. Maybe even copy-pasting something
> from the commit log?
If we move it up to something like that :
	status = nand_readl(info, NDSR);
	nand_writel(info, NDSR, status);
Then the comment is overkill I think.

> I'd like to say "Yay, let's pick it" but I'd like to make sure this is
> tested on all platforms first (unless you've tested it already).
I tested on zylonite (where bug occurs) and cm-x300 (where bug never occurs).

Cheers.

--
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ