On Thu 19-11-15 08:55:48, Dan Williams wrote: > On Thu, Nov 19, 2015 at 4:55 AM, Jan Kara <jack@xxxxxxx> wrote: > > Also are you sure that your unmapping cannot race with other process > > mapping the pfns again? > > You're right, there is indeed a gap between the unmap and when > get_blocks() will start returning errors in the fault path. I think I > need to defer the unmapping until after blk_cleanup_queue() where we > know that no new I/o to the device is possible. Yeah, you need to squeeze it somewhere after the point where get_blocks() start returning errors and before the point where pfn can go away. > > BTW what happens when you access a DAX pfn that got removed? > > SIGBUS. I don't see a way to be any kinder to the application. After > the ->remove() method for the block_device is complete we can't be > sure that the pfn is valid or even present in the system (think brd, > or VM hot provisioning). I see. So if we kept the PFN mapped, it could result e.g. in memory corruption (at least in case of brd). So we really need this to be 100% reliable. That's what I was interested in. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
