From: Boris Brezillon <boris.brezillon@free-electrons.com> To: Richard Weinberger <richard@nod.at> Cc: Brian Norris <computersforpeace@gmail.com>, linux-mtd@lists.infradead.org, dwmw2@infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mtd: Add simple read disturb test Date: Sun, 12 Apr 2015 21:31:20 +0200 [thread overview] Message-ID: <20150412213120.0414fee5@bbrezillon> (raw) In-Reply-To: <551D6BDA.6000606@nod.at> Hi Richard, On Thu, 02 Apr 2015 18:18:34 +0200 Richard Weinberger <richard@nod.at> wrote: > Am 02.04.2015 um 18:04 schrieb Brian Norris: > > On Thu, Apr 02, 2015 at 04:13:46PM +0200, Richard Weinberger wrote: > >> This simple MTD tests allows the user to see when read disturb happens. > >> By reading blocks over and over it reports flipped bits. > >> Currently it reports only flipped bits of the worst page of a block. > >> If within block X page P1 has 3 bit flips and P6 4, it will report 4. > >> By default every 50th block is read. > > > > Didn't read through this much yet, but why do we need another in-kernel > > test that coul (AFAICT) be easily replicated in userspace? The same goes > > for several of the other tests, I think, actually. But at least with > > those, we have a history of keeping them around, so it's not too much > > burden [1]. > > I've added the test to drivers/mtd/tests/ because it fits into. > As simple as that. > > > Brian > > > > [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. > > But if we want to kill drivers/mtd/tests/ I'll happily help out. I'd vote for that solution too. I've looked at in-kernel mtd tests, and I'm pretty sure they can all be done in userland. This would prevent any kernel crash caused by buggy test modules. > Where shall we move these tests into? mtd-utils? I guess so, but I'll let Brian answer that one. How about dispatching them in mtd-utils' tests/ directory (some of them are NAND related tests, so creating a tests/nand would make sense, and others are more generic). Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@free-electrons.com> To: Richard Weinberger <richard@nod.at> Cc: dwmw2@infradead.org, Brian Norris <computersforpeace@gmail.com>, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mtd: Add simple read disturb test Date: Sun, 12 Apr 2015 21:31:20 +0200 [thread overview] Message-ID: <20150412213120.0414fee5@bbrezillon> (raw) In-Reply-To: <551D6BDA.6000606@nod.at> Hi Richard, On Thu, 02 Apr 2015 18:18:34 +0200 Richard Weinberger <richard@nod.at> wrote: > Am 02.04.2015 um 18:04 schrieb Brian Norris: > > On Thu, Apr 02, 2015 at 04:13:46PM +0200, Richard Weinberger wrote: > >> This simple MTD tests allows the user to see when read disturb happens. > >> By reading blocks over and over it reports flipped bits. > >> Currently it reports only flipped bits of the worst page of a block. > >> If within block X page P1 has 3 bit flips and P6 4, it will report 4. > >> By default every 50th block is read. > > > > Didn't read through this much yet, but why do we need another in-kernel > > test that coul (AFAICT) be easily replicated in userspace? The same goes > > for several of the other tests, I think, actually. But at least with > > those, we have a history of keeping them around, so it's not too much > > burden [1]. > > I've added the test to drivers/mtd/tests/ because it fits into. > As simple as that. > > > Brian > > > > [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. > > But if we want to kill drivers/mtd/tests/ I'll happily help out. I'd vote for that solution too. I've looked at in-kernel mtd tests, and I'm pretty sure they can all be done in userland. This would prevent any kernel crash caused by buggy test modules. > Where shall we move these tests into? mtd-utils? I guess so, but I'll let Brian answer that one. How about dispatching them in mtd-utils' tests/ directory (some of them are NAND related tests, so creating a tests/nand would make sense, and others are more generic). Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
next prev parent reply other threads:[~2015-04-12 19:31 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-04-02 14:13 [PATCH] mtd: Add simple read disturb test Richard Weinberger 2015-04-02 14:13 ` Richard Weinberger 2015-04-02 14:32 ` Fabio Estevam 2015-04-02 14:32 ` Fabio Estevam 2015-04-02 14:33 ` Richard Weinberger 2015-04-02 14:33 ` Richard Weinberger 2015-04-02 14:45 ` Fabio Estevam 2015-04-02 14:45 ` Fabio Estevam 2015-04-02 14:56 ` Richard Weinberger 2015-04-02 14:56 ` Richard Weinberger 2015-04-02 15:03 ` Fabio Estevam 2015-04-02 15:03 ` Fabio Estevam 2015-04-02 15:19 ` Richard Weinberger 2015-04-02 15:19 ` Richard Weinberger 2015-04-02 15:29 ` Richard Weinberger 2015-04-02 15:29 ` Richard Weinberger 2015-04-02 15:02 ` Fabio Estevam 2015-04-02 15:02 ` Fabio Estevam 2015-04-02 15:18 ` Richard Weinberger 2015-04-02 15:18 ` Richard Weinberger 2015-04-02 16:04 ` Brian Norris 2015-04-02 16:04 ` Brian Norris 2015-04-02 16:18 ` Richard Weinberger 2015-04-02 16:18 ` Richard Weinberger 2015-04-03 5:19 ` Andrea Scian 2015-04-12 19:31 ` Boris Brezillon [this message] 2015-04-12 19:31 ` Boris Brezillon 2015-10-13 0:11 ` Brian Norris 2015-10-19 21:11 ` Richard Weinberger 2015-10-20 13:22 ` Ezequiel Garcia [not found] <mailman.39315.1427996116.22890.linux-mtd@lists.infradead.org>
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20150412213120.0414fee5@bbrezillon \ --to=boris.brezillon@free-electrons.com \ --cc=computersforpeace@gmail.com \ --cc=dwmw2@infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=richard@nod.at \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.