On Mon, 23 Nov 2015 16:06:04 -0800 Dan Williams <dan.j.williams@xxxxxxxxx> 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. I don't think I'm sufficiently understanding what this is all needed for, sorry. A better changelog would help: what's wrong with the current code, how you propose it be changed, how the kernel's externally-visible behaviour is altered, etc. Please pay particular attention to the back-compatibility issues which will be encountered when people enable these options. Perhaps when all that material is described, I'll understand why the heck we're doing this with a build-time switch rather than a runtime one... > Persistent memory presents a large "mistake surface" to /dev/mem as now > accidental writes can corrupt a filesystem. Is that the motivation? root can come in and accidentally alter persistent memory contents? If so, - why do we care? There are all sorts of ways in which root can muck up the persistent memory, starting with dd(1). What's special about /dev/mem? - why is the patch mucking with access to PCI and BIOS space? Is the persistent memory even mappable in those regions? Or is the concern that userspace can access control registers associated with the persistent memory? What is the problem scenario? IOW, a very good description of the problem-being-solved would help out a lot here... -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
