On Wed, Mar 15, 2023 at 03:35:23PM +0000, Tvrtko Ursulin wrote: > > On 15/03/2023 15:28, Kirill A. Shutemov wrote: > > On Wed, Mar 15, 2023 at 02:18:52PM +0000, Tvrtko Ursulin wrote: > > > > > > On 15/03/2023 11:31, Kirill A. Shutemov wrote: > > > > MAX_ORDER is not inclusive: the maximum allocation order buddy allocator > > > > can deliver is MAX_ORDER-1. > > > > > > This looks to be true on inspection: > > > > > > __alloc_pages(): > > > .. > > > if (WARN_ON_ONCE_GFP(order >= MAX_ORDER, gfp)) > > > > > > So a bit of a misleading name "max".. For the i915 patch: > > > > > > Acked-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > > > > > I don't however see the whole series to understand the context, or how you > > > want to handle the individual patches. Is it a tree wide cleanup of the same > > > mistake? > > > > The whole patchset can be seen here: > > > > https://lore.kernel.org/all/20230315113133.11326-1-kirill.shutemov@xxxxxxxxxxxxxxx/ > > > > The idea is to fix all MAX_ORDER bugs first and then re-define MAX_ORDER > > more sensibly. > > Sounds good. > > Would you like i915 to take this patch or you will be bringing the whole lot > via some other route? Former is okay and latter should also be fine for i915 > since I don't envisage any conflicts here. I think would be better to get it via mm tree. -- Kiryl Shutsemau / Kirill A. Shutemov
