On Thu, 14 Mar 2019, Takashi Iwai wrote: > On Thu, 14 Mar 2019 18:37:06 +0100,Hugh Dickins wrote: > > On Thu, 14 Mar 2019, Takashi Iwai wrote: > > > > > > Hugh, could you confirm whether we still need __GFP_COMP in the sound > > > buffer allocations? FWIW, it's the change introduced by the ancient > > > commit f3d48f0373c1. > > > > I'm not confident in finding all "the sound buffer allocations". > > Where you're using alloc_pages_exact() for them, you do not need > > __GFP_COMP, and should not pass it. > > It was my fault attempt to convert to alloc_pages_exact() and hitting > the incompatibility with __GFP_COMP, so it was reverted in the end. > > > But if there are other places > > where you use one of those page allocators with an "order" argument > > non-zero, and map that buffer into userspace (without any split_page()), > > there you would still need the __GFP_COMP - zap_pte_range() and others > > do the wrong thing on tail ptes if the non-zero-order page has neither > > been set up as compound nor split into zero-order pages. > > Hm, what if we allocate the whole pages via alloc_pages_exact() (but > without __GFP_COMP)? Can we mmap them properly to user-space like > before, or it won't work as-is? Yes, you can map the alloc_pages_exact() pages to user-space as before, whether or not it ended up using a whole non-zero-order page: alloc_pages_exact() does a split_page(), so the subpages end up all just ordinary order-zero pages (and need to be freed individually, which free_pages_exact() does for you). Hugh
