On Thu, 14 Mar 2019 19:15:22 +0100, Hugh Dickins wrote: > > 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). Great, thanks for clarification! Takashi
