linux-kernel - Re: [PATCH] mtd: Add simple read disturb test

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: <551E22E2.80200@dave-tech.it>
Date:	Fri, 03 Apr 2015 07:19:30 +0200
From:	Andrea Scian <rnd4@...e-tech.it>
To:	linux-mtd@...ts.infradead.org, Richard Weinberger <richard@....at>
CC:	Brian Norris <computersforpeace@...il.com>, dwmw2@...radead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mtd: Add simple read disturb test

Hi all,

Il 02/04/2015 18:18, Richard Weinberger ha scritto:
> Am 02.04.2015 um 18:04 schrieb Brian Norris:
>> On Thu, Apr 02, 2015 at 04:13:46PM +0200, Richard Weinberger wrote:
>> [1] Although there are some latent issues in these tests that are still
>> getting get worked out (e.g., bad handling of 64-bit casting; too large
>> of stacks; uninterruptibility). The latter two would not even exist if
>> we were in user space.
> 
> uninterruptibility got solved by my "[PATCH] mtd: Make MTD tests cancelable" patch.

And this is something I was looking for from years!

> But if we want to kill drivers/mtd/tests/ I'll happily help out.
> Where shall we move these tests into? mtd-utils?

I think so.
I'm writing a similar read disturb test on my own, mixing already
existing mtd-tools (flash_erase, nandwrite, nanddump) with some naive
bash scripting.
IMHO, we have a lot of pros running in userspace:
* dumping data
* better error/status log (which can be easily written on file, for
example, while mtdtests error log is mixed with other kernel messages)
* running test in parallel (if it make sense ;-)

For example on read disturb I already calculate RBER, which is, AFAIK, a
nice index on the quality of the NAND cell and of its data. I'm working
on writing down data on a separate CSV which can be easily processed
later (e.g. to make part to part comparison/statistics).

There's already a test directory inside mtd-utils, I think it's better
to start creating tests there, as userspace tools, whenever this is
possible.
Do we have any reason to have MTD tests as kernel module? (performance?)

Kind Regards,

-- 

Andrea SCIAN

DAVE Embedded Systems
--
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/