There's a bit back story there, so as a fun historical note, let me recount it here. In 2016, there was the Dirty CoW exploit (CVE-2016-5195), which got fixed by Linus in 19be0eaff [1]. Unfortunately, in that patch he forgot about transparent huge pages (they're easy to forget ;), which caused processes to lock up if you were using FOLL_FORCE on a memory range that happened to be backed by thp. That patch was widely backported to stable kernels, so I soon noticed my processes randomly freezing on various Linux machines. With a bit of debugging, I sent in a patch to fix that (https://lore.kernel.org/patchwork/patch/748110/), though I'm not sure that Linus ever saw it (or I guess he could have assumed we were using ptrace). Nevertheless, I assume that this being a common exploit vector for DirtyCoW made him want to remove it. As a result that was of course the second time within the course of six months that this stopped working (plus Linus' fault both times), so that email was written from a bit of a "you've got to be kidding me" mindset.
As an addendum in writing this comment, I became aware that my patch to fix FOLL_FORCE with thp actually re-introduced a version of the original DirtyCoW exploit apparently known as HugeDirtyCoW (CVE-2017–1000405) [2] - or rather my patch interacted badly with a pre-existing mistake in the thp code and caused this. Oops.
As an addendum in writing this comment, I became aware that my patch to fix FOLL_FORCE with thp actually re-introduced a version of the original DirtyCoW exploit apparently known as HugeDirtyCoW (CVE-2017–1000405) [2] - or rather my patch interacted badly with a pre-existing mistake in the thp code and caused this. Oops.
[1] https://github.com/torvalds/linux/commit/19be0eaff [2] https://medium.com/bindecy/huge-dirty-cow-cve-2017-1000405-1...