On Mon, Jun 11, 2018 at 2:58 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 18 May 2018 18:35:08 -0700 Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > >> get_user_pages_fast() for device pages is missing the typical validation >> that all page references have been taken while the mapping was valid. >> Without this validation truncate operations can not reliably coordinate >> against new page reference events like O_DIRECT. >> >> Cc: <stable@xxxxxxxxxxxxxxx> > > I'm not seeing anything in the changelog which justifies a -stable > backport. ie: a description of the end-user-visible effects of the > bug? > Without this change get_user_pages_fast() could race truncate. The ordering of page_cache_add_speculative() before re-validating the mapping allows truncate and page freeing to synchronize against get_user_pages_fast(). Specifically, a get_user_pages_fast() thread could continue allowing a page to be mapped and accessed via the kernel mapping after it was meant to be torn down. This could cause unexpected data corruption or access to the physical page after it has been invalidated from process page tables. Ideally I think we would go further than this patch and backport the full fix for the filesystem-dax-vs-truncate problem. I was planning to spin up a 4.14 backport with the full set of the pieces that went into 4.17 and 4.18.
