Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751934AbdF2GYb (ORCPT ); Thu, 29 Jun 2017 02:24:31 -0400 Received: from mail-wr0-f173.google.com ([209.85.128.173]:33580 "EHLO mail-wr0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751614AbdF2GYY (ORCPT ); Thu, 29 Jun 2017 02:24:24 -0400 MIME-Version: 1.0 In-Reply-To: <20170628170742.2895-1-opendmb@gmail.com> References: <20170628170742.2895-1-opendmb@gmail.com> From: Gregory Fong Date: Wed, 28 Jun 2017 23:23:52 -0700 Message-ID: Subject: Re: [PATCH] cma: fix calculation of aligned offset To: Doug Berger Cc: Angus Clark , Andrew Morton , Laura Abbott , Vlastimil Babka , Greg Kroah-Hartman , Lucas Stach , Catalin Marinas , Shiraz Hashim , Jaewon Kim , "open list:MEMORY MANAGEMENT" , open list , Danesh Petigara Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1584 Lines: 34 On Wed, Jun 28, 2017 at 10:07 AM, Doug Berger wrote: > The align_offset parameter is used by bitmap_find_next_zero_area_off() > to represent the offset of map's base from the previous alignment > boundary; the function ensures that the returned index, plus the > align_offset, honors the specified align_mask. > > The logic introduced by commit b5be83e308f7 ("mm: cma: align to > physical address, not CMA region position") has the cma driver > calculate the offset to the *next* alignment boundary. Wow, I had that completely backward, nice catch. > In most cases, > the base alignment is greater than that specified when making > allocations, resulting in a zero offset whether we align up or down. > In the example given with the commit, the base alignment (8MB) was > half the requested alignment (16MB) so the math also happened to work > since the offset is 8MB in both directions. However, when requesting > allocations with an alignment greater than twice that of the base, > the returned index would not be correctly aligned. It may be worth explaining what impact incorrect alignment has for an end user, then considering for inclusion in stable. > > Also, the align_order arguments of cma_bitmap_aligned_mask() and > cma_bitmap_aligned_offset() should not be negative so the argument > type was made unsigned. > > Fixes: b5be83e308f7 ("mm: cma: align to physical address, not CMA region position") > Signed-off-by: Angus Clark > Signed-off-by: Doug Berger Acked-by: Gregory Fong