On Wed, Apr 2, 2014 at 10:58 AM, Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > On Wed, Apr 02, 2014 at 10:40:16AM -0700, John Stultz wrote: >> That point beside, I think the other problem with the page-cleaning >> volatility approach is that there are other awkward side effects. For >> example: Say an application marks a range as volatile. One page in the >> range is then purged. The application, due to a bug or otherwise, >> reads the volatile range. This causes the page to be zero-filled in, >> and the application silently uses the corrupted data (which isn't >> great). More problematic though, is that by faulting the page in, >> they've in effect lost the purge state for that page. When the >> application then goes to mark the range as non-volatile, all pages are >> present, so we'd return that no pages were purged. From an >> application perspective this is pretty ugly. >> >> Johannes: Any thoughts on this potential issue with your proposal? Am >> I missing something else? > > No, this is accurate. However, I don't really see how this is > different than any other use-after-free bug. If you access malloc > memory after free(), you might receive a SIGSEGV, you might see random > data, you might corrupt somebody else's data. This certainly isn't > nice, but it's not exactly new behavior, is it? The part that troubles me is that I see the purged state as kernel data being corrupted by userland in this case. The kernel will tell userspace that no pages were purged, even though they were. Only because userspace made an errant read of a page, and got garbage data back. thanks -john -- 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>