The patch titled
Subject: cma: fix calculation of aligned offset
has been added to the -mm tree. Its filename is
cma-fix-calculation-of-aligned-offset.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/cma-fix-calculation-of-aligned-offset.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/cma-fix-calculation-of-aligned-offset.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Doug Berger <opendmb@xxxxxxxxx>
Subject: cma: fix calculation of aligned offset
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.
Fixes: b5be83e308f7 ("mm: cma: align to physical address, not CMA region position")
Link: http://lkml.kernel.org/r/20170628170742.2895-1-opendmb@xxxxxxxxx
Signed-off-by: Angus Clark <angus@xxxxxxxxxxxxxx>
Signed-off-by: Doug Berger <opendmb@xxxxxxxxx>
Cc: Gregory Fong <gregory.0xf0@xxxxxxxxx>
Cc: Doug Berger <opendmb@xxxxxxxxx>
Cc: Angus Clark <angus@xxxxxxxxxxxxxx>
Cc: Laura Abbott <labbott@xxxxxxxxxx>
Cc: Vlastimil Babka <vbabka@xxxxxxx>
Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Cc: Lucas Stach <l.stach@xxxxxxxxxxxxxx>
Cc: Catalin Marinas <catalin.marinas@xxxxxxx>
Cc: Shiraz Hashim <shashim@xxxxxxxxxxxxxx>
Cc: Jaewon Kim <jaewon31.kim@xxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/cma.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff -puN mm/cma.c~cma-fix-calculation-of-aligned-offset mm/cma.c
--- a/mm/cma.c~cma-fix-calculation-of-aligned-offset
+++ a/mm/cma.c
@@ -59,7 +59,7 @@ const char *cma_get_name(const struct cm
}
static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
- int align_order)
+ unsigned int align_order)
{
if (align_order <= cma->order_per_bit)
return 0;
@@ -67,17 +67,14 @@ static unsigned long cma_bitmap_aligned_
}
/*
- * Find a PFN aligned to the specified order and return an offset represented in
- * order_per_bits.
+ * Find the offset of the base PFN from the specified align_order.
+ * The value returned is represented in order_per_bits.
*/
static unsigned long cma_bitmap_aligned_offset(const struct cma *cma,
- int align_order)
+ unsigned int align_order)
{
- if (align_order <= cma->order_per_bit)
- return 0;
-
- return (ALIGN(cma->base_pfn, (1UL << align_order))
- - cma->base_pfn) >> cma->order_per_bit;
+ return (cma->base_pfn & ((1UL << align_order) - 1))
+ >> cma->order_per_bit;
}
static unsigned long cma_bitmap_pages_to_bits(const struct cma *cma,
_
Patches currently in -mm which might be from opendmb@xxxxxxxxx are
cma-fix-calculation-of-aligned-offset.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
