linux-kernel - Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um

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] [day] [month] [year] [list]

Date:	Thu, 06 Jan 2011 15:45:34 +0000
From:	David Woodhouse <dwmw2@...radead.org>
To:	Jason Lunz <lunz@....org>
Cc:	Artem Bityutskiy <dedekind1@...il.com>,
	richard -rw- weinberger <richard.weinberger@...il.com>,
	Sam Ravnborg <sam@...nborg.org>,
	atom ota <atomota@...epyhammer.com>,
	user-mode-linux-devel@...ts.sourceforge.net,
	Jeff Dike <jdike@...toit.com>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-mtd@...ts.infradead.org, Rob Landley <rob@...dley.net>
Subject: Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um

On Tue, 2010-12-14 at 11:51 -0800, Jason Lunz wrote:
> 
> > Instead, you should solve this problem in UML code. I do not know how,
> > but may be you can add readb/writeb there which actually do nothing or
> > print a scary warning, or do BUG(), and let things which use them just
> > fail run-time.
> 
> Something like this could work, but it would be error-prone for anyone
> else who attempts using iomem-requiring drivers on uml. Instead of
> getting obvious compile failures we'd have broken drivers that BUG() or
> emit scary warnings. That doesn't seem to me like an improvement. 

Drivers should *never* BUG() or crash, or busy-loop, on getting 0xFF
when they read from hardware. That can happen anyway in some
circumstances.

Doesn't iSeries take this approach?

I don't much like the patch that Artem took into his l2-mtd tree; it
doesn't even let you build mtdchar, which really *ought* to be
permitted. It also didn't allow the nandsim or mtdram devices, which are
purely virtual.

I think I'd prefer something similar to your original, Jason. I don't
think the HAS_IOMEM dependencies have to be *so* complex to maintain. If
anything we're just going to err on the side of inclusion and you'll
occasionally have to send us patches to "hide" things from you again.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

--
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/