On Fri, Nov 20, 2015 at 12:00 PM, Arnd Bergmann <a...@arndb.de> wrote: > On Friday 20 November 2015 09:31:33 Dan Williams wrote: >> This effectively promotes IORESOURCE_BUSY to IORESOURCE_EXCLUSIVE >> semantics by default. If userspace really believes it is safe to access >> the memory region it can also perform the extra step of disabling an >> active driver. This protects device address ranges with read side >> effects and otherwise directs userspace to use the driver. >> >> Persistent memory presents a large "mistake surface" to /dev/mem as now >> accidental writes can corrupt a filesystem. >> >> Cc: Kees Cook <keesc...@chromium.org> >> Cc: Russell King <li...@arm.linux.org.uk> >> Cc: Catalin Marinas <catalin.mari...@arm.com> >> Cc: Will Deacon <will.dea...@arm.com> >> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> >> Cc: Martin Schwidefsky <schwidef...@de.ibm.com> >> Cc: Heiko Carstens <heiko.carst...@de.ibm.com> >> Cc: Thomas Gleixner <t...@linutronix.de> >> Cc: Ingo Molnar <mi...@redhat.com> >> Cc: "H. Peter Anvin" <h...@zytor.com> >> Cc: Andrew Morton <a...@linux-foundation.org> >> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> >> Signed-off-by: Dan Williams <dan.j.willi...@intel.com> >> > > I like the idea.
Yes please! I was always surprised that IORESOURCE_BUSY was allowed under STRICT_DEVMEM. > Maybe split the change up into two patches, where the first one > just does the trivial move of the Kconfig option, and the second > one that changes behavior is small? Agreed: consolidate the per-arch Kconfigs first. > There is also a question of whether we actually need two options > or if we can safely make the existing option stricter. Right -- what actually breaks if we add _BUSY to getting blocked? -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
