From: Mel Gorman > Sent: 21 March 2023 16:39 > > On Wed, Mar 15, 2023 at 02:31:23PM +0300, Kirill A. Shutemov wrote: > > MAX_ORDER currently defined as number of orders page allocator supports: > > user can ask buddy allocator for page order between 0 and MAX_ORDER-1. > > > > This definition is counter-intuitive and lead to number of bugs all over > > the kernel. > > > > Fix the bugs and then change the definition of MAX_ORDER to be > > inclusive: the range of orders user can ask from buddy allocator is > > 0..MAX_ORDER now. > > > > Acked-by: Mel Gorman <mgorman@xxxxxxx> > > Overall looks sane other than the fixups that need to be added as > flagged by LKP. There is a mild risk for stable backports that reference > MAX_ORDER but that's the responsibilty of who is doing the backport. > There is a mild risk of muscle memory adding off-by-one errors for new > code using MAX_ORDER but it's low. How many of the places that use MAX_ORDER weren't touched? Is it actually worth changing the name at the same time. That will stop stable backport issues. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
