On 08/13/2015 05:41 PM, Christoph Hellwig wrote: > On Thu, Aug 13, 2015 at 04:23:38PM +0300, Boaz Harrosh wrote: >>> DAX as is is races against pmem unbind. A synchronization cost must >>> be paid somewhere to make sure the memremap() mapping is still valid. >> >> Sorry for being so slow, is what I asked. what is exactly "pmem unbind" ? >> >> Currently in my 4.1 Kernel the ioremap is done on modprobe time and >> released modprobe --remove time. the --remove can not happen with a mounted >> FS dax or not. So what is exactly "pmem unbind". And if there is a new knob >> then make it refuse with a raised refcount. > > Surprise removal of a PCIe card which is mapped to provide non-volatile > memory for example. Or memory hot swap. > Then the mapping is just there and you get garbage. Just the same as "memory hot swap" the kernel will not let you HOT-REMOVE a referenced memory. It will just refuse. If you forcefully remove a swapeble memory chip without HOT-REMOVE first what will happen? so the same here. SW wise you refuse to HOT-REMOVE. HW wise BTW the Kernel will not die only farther reads will return all 111111 and writes will go to the either. The all kmap thing was for highmem. Is not the case here. Again see my other comment at dax mmap: - you go pfn_map take a pfn - kpfn_unmap - put pfn on user mmap vma - then what happens to user access after that. Nothing not even a page_fault It will have a vm-mapping to a now none existing physical address that's it. Thanks Boaz -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>