On Tue 30-09-14 09:39:17, Thanos Makatos wrote: > > On Tue 30-09-14 08:58:54, Thanos Makatos wrote: > > > > > If the above observations are correct, it seems that I have to > > > > > either extend BLKFLSBUF to some invalidate such memory maps (I'm > > > > > completely ignorant in that field, is it even possible?), or look > > > > > for other solutions. > > > > Well, you could unmap the pages of block device that are mapped in > > > > your new ioctl but I don't think it's easily possible to disallow > > > > userspace to fault the pages back behind your back. And that could be a > > problem for you. > > > > > > I'm not sure I understand what "I don't think it's easily possible to > > > disallow userspace to fault the pages back behind your back" means, > > > could you explain? > > I mean by that that even if you evict page from page cache, it can be > > immediately reloaded from the device. So you have to be careful to provide > > new data once you decide to go and evict page cache. But that's obvious I > > guess. > > > > > I definitely don't care what happens to the process that dared to > > > memory map the block device, this configuration is not supported in my > > > environment. Is this what you mean? > > OK, so it isn't supported but you don't want such application to be able to > > screw up your other processes, am I right? > > I realise I haven't given enough context to my scenario, I'll try to > better explain myself: there is a known set of processes that use the > block device in a very specific and predictable way (never via mmap), and > they are fully under my control. I don't care what happens to any other > process, I don't even care if it crashes, sees the wrong data, or > segfaults. OK. > When I issue the ioctl (modified to evict pages from the page cache), I > can guarantee that all of my process do not access the block device, I > can even force them to close it while the modified ioctl executes. You > say that "that even if you evict page from page cache, it can be > immediately reloaded from the device", does this mean that that "unknown" > process can access the block device via mmap and fetch "stale" pages > while I'm executing the ioctl, effectively undoing what the ioctl did? If > this is the case, the buffer cache will contain the wrong data and that > will result in corruption. Yes, "unknown" process can read data back into pagecache while your ioctl is running thus undoing your work. But if the writes are already visible on the *device* at the moment you run the ioctl, then "unknown" process will just fetch new data and everything is fine... If you need to evict page cache *before* new data is visible on the device, then you need to suspend the device first so that it doesn't serve any IO, then evict page cache, then make new data visible on the device, and finally resume the device. Suspend/resume of the device can be handled by device mapper (it does these tricks when you are changing topology of the device on the fly). Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
