On 10/19/2015 04:18 PM, Andrew Morton wrote: > On Fri, 16 Oct 2015 15:08:27 -0700 Mike Kravetz <[email protected]> > wrote: > >> The hugetlbfs fallocate hole punch code can race with page faults. The >> result is that after a hole punch operation, pages may remain within the >> hole. No other side effects of this race were observed. >> >> In preparation for adding userfaultfd support to hugetlbfs, it is desirable >> to plug or significantly shrink this hole. This patch set uses the same >> mechanism employed in shmem (see commit f00cdc6df7). >> > > "still buggy but not as bad as before" isn't what we strive for ;) What > would it take to fix this for real? An exhaustive description of the > bug would be a good starting point, thanks. >
Thanks for asking, it made me look closer at ways to resolve this. The current code in remove_inode_hugepages() does nothing with a page if it is still mapped. The only way it can be mapped is if we race and take a page fault after unmapping, but before the page is removed. This patch set makes that window much smaller, but it still exists. Instead of "giving up" on a mapped page, remove_inode_hugepages() can go back and unmap it. I'll code this up tomorrow. Fortunately, it is pretty easy to hit these races and verify proper behavior. I'll create a new patch set with this combined code for a complete fix. -- Mike Kravetz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
