Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp968835imm; Fri, 5 Oct 2018 15:20:18 -0700 (PDT) X-Google-Smtp-Source: ACcGV61M8if1NBxV478yQp8vkTu11V8JGSTdPfaAw73zMBOe6if6Rv6eJIgWGdMp2eXi3lVOLjNr X-Received: by 2002:a63:6bc2:: with SMTP id g185-v6mr12110688pgc.25.1538778018740; Fri, 05 Oct 2018 15:20:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538778018; cv=none; d=google.com; s=arc-20160816; b=ecWUQeCgupA9MRGBm69eLH2WbdHDEd/Gt7iAxrv6JiZ2jsy4fa9Zeb/vcya9eCa8u9 wawm2+xIhM8HUP5jd28EFT5XXvxIxu9c5sifZDixZU2ncP8Zvb1jiHOWx4XR9w7wxKb/ fkpcEr4ByKBwDKnxS6KMIwpBmua5MV83xSkY0Ry7+eYr5hyjK04Qjdev5whEeWjUAFw0 CA7VcpOHmkkxYmgmZConxtLNBsPmgLLVNhhSd4URiAXjoe9V+TUqtjCP2GQIoRuwV2pp RKvmCto03hXlBiuzBPDNbtYSgiX+UscwcwFBm5ris+3KMDAF7QfgJGQyKANeamEDt2Db Zpdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=U6/ryzMj+UYQjIsJmYasy8TYxqGsYTBhDo/i4qh0qsk=; b=qFFLZAszDCqTQ4NkonP0FPqV+5Ov9ySOaVn3uuGAp0aC1K4tezgVOLXiSc6PG9bLMF zcJUxhzBKejfdDZh7349XmB5zgb/wlCzjp8xfS4YfCmJD5sUL0g4n7N3EGkNyk9gnOhq fE/m2MncPBQLuKWANoPBHFryLRA1QHMobSdSVJhTHQFLpEjrSc2udERwPT+PWYkWtidp L7juWByEAzg4Akor/ZghuHj+bvHHT3gKK1VTDxUf4BoUMNcnG6EeVb9c5UEn+pdsWvlt 8+O+7p5x9YZMmsRv4TK1JqZTqxH4p17LiogJkDnNas0rhNcLdwjRzmNYMesIv1VRoQLb K0ig== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 4-v6si10529021pfe.142.2018.10.05.15.20.03; Fri, 05 Oct 2018 15:20:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729262AbeJFFUV (ORCPT + 99 others); Sat, 6 Oct 2018 01:20:21 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:49476 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726399AbeJFFUV (ORCPT ); Sat, 6 Oct 2018 01:20:21 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.8.65]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 5A51BD22; Fri, 5 Oct 2018 22:19:35 +0000 (UTC) Date: Fri, 5 Oct 2018 15:19:34 -0700 From: Andrew Morton To: Mike Rapoport Cc: linux-mm@kvack.org, Catalin Marinas , Chris Zankel , Geert Uytterhoeven , Guan Xuetao , Ingo Molnar , Matt Turner , Michael Ellerman , Michal Hocko , Michal Simek , Paul Burton , Richard Weinberger , Russell King , Thomas Gleixner , Tony Luck , linux-alpha@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@vger.kernel.org, linux-mips@linux-mips.org, linuxppc-dev@lists.ozlabs.org, linux-um@lists.infradead.org Subject: Re: [PATCH] memblock: stop using implicit alignement to SMP_CACHE_BYTES Message-Id: <20181005151934.87226fa92825c3002a475413@linux-foundation.org> In-Reply-To: <1538687224-17535-1-git-send-email-rppt@linux.vnet.ibm.com> References: <1538687224-17535-1-git-send-email-rppt@linux.vnet.ibm.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 5 Oct 2018 00:07:04 +0300 Mike Rapoport 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.