> 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. 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. -- 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
