[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20181005151934.87226fa92825c3002a475413@linux-foundation.org>
Date: Fri, 5 Oct 2018 15:19:34 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Mike Rapoport <rppt@...ux.vnet.ibm.com>
Cc: linux-mm@...ck.org, Catalin Marinas <catalin.marinas@....com>,
Chris Zankel <chris@...kel.net>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Guan Xuetao <gxt@....edu.cn>, Ingo Molnar <mingo@...hat.com>,
Matt Turner <mattst88@...il.com>,
Michael Ellerman <mpe@...erman.id.au>,
Michal Hocko <mhocko@...e.com>,
Michal Simek <monstr@...str.eu>,
Paul Burton <paul.burton@...s.com>,
Richard Weinberger <richard@....at>,
Russell King <linux@...linux.org.uk>,
Thomas Gleixner <tglx@...utronix.de>,
Tony Luck <tony.luck@...el.com>, linux-alpha@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-ia64@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-m68k@...r.kernel.org,
linux-mips@...ux-mips.org, linuxppc-dev@...ts.ozlabs.org,
linux-um@...ts.infradead.org
Subject: Re: [PATCH] memblock: stop using implicit alignement to
SMP_CACHE_BYTES
On Fri, 5 Oct 2018 00:07:04 +0300 Mike Rapoport <rppt@...ux.vnet.ibm.com> wrote:
> When a memblock allocation APIs are called with align = 0, the alignment is
> implicitly set to SMP_CACHE_BYTES.
>
> Replace all such uses of memblock APIs with the 'align' parameter explicitly
> set to SMP_CACHE_BYTES and stop implicit alignment assignment in the
> memblock internal allocation functions.
>
> For the case when memblock APIs are used via helper functions, e.g. like
> iommu_arena_new_node() in Alpha, the helper functions were detected with
> Coccinelle's help and then manually examined and updated where appropriate.
>
> ...
>
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1298,9 +1298,6 @@ static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size,
> {
> phys_addr_t found;
>
> - if (!align)
> - align = SMP_CACHE_BYTES;
> -
Can we add a WARN_ON_ONCE(!align) here? To catch unconverted code
which sneaks in later on.
Powered by blists - more mailing lists