LWN: Comments on "Tracking pages from get_user_pages()"

Tracking pages from get_user_pages()

corbet — Sat, 20 Apr 2019 03:35:11 +0000

That is done now, but the mappings in question aren't affected by it. Devices don't care about protections in page-table entries.

Tracking pages from get_user_pages()

quotemstr — Sat, 20 Apr 2019 02:50:01 +0000

Can't we clear PROT_WRITE from user pages with in-flight disk writes? rmap would let us find all the PTEs that point to such a page.

Tracking pages from get_user_pages()

rweikusat2 — Thu, 18 Apr 2019 19:35:16 +0000

uintptr_t is just an integer as well. If it exists, it's a typedef name for an unsigned integer type which is large enough to store a pointer value. As page frame numbers are smaller than pointers due to coarser granularity, that's obviously not a property which would be needed here but it wouldn't do any harm, either.

Tracking pages from get_user_pages()

willy — Thu, 18 Apr 2019 18:28:20 +0000

PFNs are most definitely not uintptr_t. For example, on a 32-bit platform with PAE, PFNs can use up to 28 bits, letting us support up to 1TB of memory with a 4kB page size. They really are just an integer.

Fixed

corbet — Thu, 18 Apr 2019 17:17:22 +0000

Yes, that was a mistake; fixed now.

Tracking pages from get_user_pages()

stevie-oh — Thu, 18 Apr 2019 17:13:55 +0000

I'm assuming that instead of "unsigned long *bv_pfn" the article should read "unsigned long bv_pfn" (which I personally believe ought to be uintptr_t, but that's another story.)