Hi On Mon, Jun 2, 2014 at 11:14 AM, Jan Kara <jack@xxxxxxx> wrote: > On Mon 02-06-14 13:42:59, Minchan Kim wrote: >> On Mon, May 19, 2014 at 01:44:25PM +0200, David Herrmann wrote: >> > I tried doing the page-replacement in the last 4 days, but honestly, >> > it's far more complex than I thought. So if no-one more experienced >> > with mm/ comes up with a simple implementation, I'll have to delay >> > this for some more weeks. >> > >> > However, I still wonder why we try to fix this as part of this >> > patchset. Using FUSE, a DIRECT-IO call can be delayed for an arbitrary >> > amount of time. Same is true for network block-devices, NFS, iscsi, >> > maybe loop-devices, ... This means, _any_ once mapped page can be >> > written to after an arbitrary delay. This can break any feature that >> > makes FS objects read-only (remounting read-only, setting S_IMMUTABLE, >> > sealing, ..). >> > >> > Shouldn't we try to fix the _cause_ of this? >> >> I didn't follow this patchset and couldn't find what's your most cocern >> but at a first glance, it seems you have troubled with pinned page. >> If so, it's really big problem for CMA and I think peterz's approach(ie, >> mm_mpin) is really make sense to me. > Well, his concern are pinned pages (and also pages used for direct IO and > similar) but not because they are pinned but because they can be modified > while someone holds reference to them. So I'm not sure Peter's patches will > help here. Correct, the problem is not accounting for pinned-pages, but waiting for them to get released. Furthermore, Peter's patches make VM_PINNED an optional feature, so we'd still miss all the short-term GUP users. Sadly, that means we cannot even use it to test for pending GUP users. Thanks David -- 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
