linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Berger <opendmb@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Gregory Fong <gregory.0xf0@gmail.com>,
	Angus Clark <angus@angusclark.org>,
	Laura Abbott <labbott@redhat.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Lucas Stach <l.stach@pengutronix.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Shiraz Hashim <shashim@codeaurora.org>,
	Jaewon Kim <jaewon31.kim@samsung.com>,
	"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cma: fix calculation of aligned offset
Date: Thu, 29 Jun 2017 17:43:18 -0700	[thread overview]
Message-ID: <b9185ff5-1468-4605-36c7-c856e830b9e2@gmail.com> (raw)
In-Reply-To: <20170629134810.3a5b09dbdea001cca72080ce@linux-foundation.org>

On 06/29/2017 01:48 PM, Andrew Morton wrote:
> On Wed, 28 Jun 2017 10:07:41 -0700 Doug Berger <opendmb@gmail.com> 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.  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.
>>
>> 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.
> 
> The changelog doesn't describe the user-visible effects of the bug.  It
> should do so please, so that others can decide which kernel(s) need the fix.
> 
> Since the bug has been there for three years, I'll assume that -stable
> backporting is not needed.
> 
I'm afraid I'm confused by what you are asking me to do since it appears
that you have already signed-off on this patch.

The direct user-visible effect of the bug is that if the user requests a
CMA allocation that is aligned with a granule that is more than twice
the base alignment of the CMA region she will receive an allocation that
does not have that alignment.

As I indicated to Gregory, the follow-on consequences of the address not
satisfying the required alignment depend on why the alignment was
requested.  In our case it was a system crash, but it could also
manifest as data corruption on a network interface for example.

In general I would expect it to be unusual for anyone to request an
allocation alignment that is larger than the CMA base alignment which is
probably why the bug has been hiding for three years.

Thanks for your support with this and let me know what more you would
like from me.

-Doug

  reply	other threads:[~2017-06-30  0:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-28 17:07 [PATCH] cma: fix calculation of aligned offset Doug Berger
2017-06-29  6:23 ` Gregory Fong
2017-06-29 16:54   ` Doug Berger
2017-06-29 20:48 ` Andrew Morton
2017-06-30  0:43   ` Doug Berger [this message]
2017-06-30  0:49     ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b9185ff5-1468-4605-36c7-c856e830b9e2@gmail.com \
    --to=opendmb@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=angus@angusclark.org \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gregory.0xf0@gmail.com \
    --cc=jaewon31.kim@samsung.com \
    --cc=l.stach@pengutronix.de \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=shashim@codeaurora.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).