Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753023AbdF2QzC (ORCPT ); Thu, 29 Jun 2017 12:55:02 -0400 Received: from mail-qt0-f193.google.com ([209.85.216.193]:34262 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751333AbdF2Qyy (ORCPT ); Thu, 29 Jun 2017 12:54:54 -0400 Subject: Re: [PATCH] cma: fix calculation of aligned offset To: Gregory Fong 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 References: <20170628170742.2895-1-opendmb@gmail.com> From: Doug Berger Message-ID: <06989e55-b062-5312-1b26-f6db39153f7a@gmail.com> Date: Thu, 29 Jun 2017 09:54:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2237 Lines: 48 On 06/28/2017 11:23 PM, Gregory Fong wrote: > 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. Thanks go to Angus for that! >> 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. It would be difficult to explain in a general way since the end user is requesting the alignment and only she knows what the consequences would be for insufficient alignment. I assume in general with the CMA it is most likely a DMA constraint. However, in our particular case the problem affected an allocation used by a co-processor. The larger CONFIG_CMA_ALIGNMENT is the less likely users would run into this bug. We encountered it after reducing our default CONFIG_CMA_ALIGNMENT. I agree that it should be considered for 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 >