On Fri, Nov 20, 2015 at 12:00 PM, Arnd Bergmann <[email protected]> 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 <[email protected]> >> Cc: Russell King <[email protected]> >> Cc: Catalin Marinas <[email protected]> >> Cc: Will Deacon <[email protected]> >> Cc: Benjamin Herrenschmidt <[email protected]> >> Cc: Martin Schwidefsky <[email protected]> >> Cc: Heiko Carstens <[email protected]> >> Cc: Thomas Gleixner <[email protected]> >> Cc: Ingo Molnar <[email protected]> >> Cc: "H. Peter Anvin" <[email protected]> >> Cc: Andrew Morton <[email protected]> >> Cc: Greg Kroah-Hartman <[email protected]> >> Signed-off-by: Dan Williams <[email protected]> >> > > 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
