Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp4270924ybc; Tue, 26 Nov 2019 06:34:12 -0800 (PST) X-Google-Smtp-Source: APXvYqwv5bG+nju1E9ZHha5kX+0iMQEDb/9BhxnTqO+8d9fE8mvdHK8IbryBKem6OdfWmcOHJlVi X-Received: by 2002:a50:f7cb:: with SMTP id i11mr26204930edn.194.1574778852452; Tue, 26 Nov 2019 06:34:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574778852; cv=none; d=google.com; s=arc-20160816; b=kgN2iRx1/syyTuT8dnVkdc9pQEo1ens3gyAYmoa/K7RKwf8TM9oMEv1cw92f+b9m8z 6GCNNgCwAJPhAkCshCZWVViNa9qKPvJfrnp9XNSEdi5MdL7rC6criU8GjZsjEY9HnZPJ J94ooQ4Z80yeiSH06GeBHDsIWhMsOCTQ+/NEksZX2eP9c5lTLPSdN971xvWCnI6pBfHm b8xiD9dFvaL4PCQcqnpHB1ZiWcCq7cXRj6vR80wMixbV2wLMLI9QkX9AbrOQ4ps5Izd7 tP2sIph3UIK+x/eHQPK1lMFhK/be04YhqOQiI4G5oEBxDIOFXy3lgFKHkenjhxEVgLOJ +YIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=KPOiBiMl69XGQDBmycxuawKOxsJQrxoI/O+sj/Y0vXA=; b=IrTyZvWBYN6jcjU+VVxlN0CCO7M9AZnqjYR/OWP7EVHfMJz3EIDvN2J8NgZZrCIDOn JaFohj94CCDc+qUti1/fJdkQSQTq3ucTUWOagobHOfCCGA/UqFUB/jvywggdVMVqt0sP ol5DjUbg4pBJ90pdPKDt99ww1NTBzJoHtJ5eCcBcNUxvNprRW36QYva3dw+oF/L/AYIz rlZwvQqEQOkEBvG1Riea+ZSMe2khqa2LFtKQxdsJVG0/FJynRunEgixaX/r2zguHB0cL gp0Fwv6wtEzKY94fGnm7wkQvQKEC/IsurdNDLy5qRPIkuP1bIWlyiVx+ZadYgHcZbPpT p2DA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Dw4HY62q; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h36si8235179eda.206.2019.11.26.06.33.46; Tue, 26 Nov 2019 06:34:12 -0800 (PST) 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; dkim=pass header.i=@google.com header.s=20161025 header.b=Dw4HY62q; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728090AbfKZOGe (ORCPT + 99 others); Tue, 26 Nov 2019 09:06:34 -0500 Received: from mail-ot1-f68.google.com ([209.85.210.68]:43934 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727568AbfKZOGe (ORCPT ); Tue, 26 Nov 2019 09:06:34 -0500 Received: by mail-ot1-f68.google.com with SMTP id l14so15925750oti.10 for ; Tue, 26 Nov 2019 06:06:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KPOiBiMl69XGQDBmycxuawKOxsJQrxoI/O+sj/Y0vXA=; b=Dw4HY62q40JV7BWYlZLIGz6S96Cm9bMj0Wo2km15nIQqLH4Zz1BRw3dQ/buGO6/QKT VAbL+EQPXdreE9r3cyH9Y7aYzcgZf8ZuiXYYqVpXYxvEyEh5NLsVoyP8FArwOm09+epk gbIh/Fl1NfFWge9SfqKz7ndd/sLU9KZJcMEDZBGdVCuoZ8nCvXWlEOrKEWAOYcYqri93 wqwjrAwg+1XtW+uHIGzIdS77RKa+gCzdoD0D8cJRnlKqu+6hVW+bkhPk8k8nNsZhxRqs F1wa6fQYMHOJd5trEjadiYOAr2PEXZpG4NiGuCyL7x8vnRQYbV8O9/sUvVNCWtyunhXH BBpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KPOiBiMl69XGQDBmycxuawKOxsJQrxoI/O+sj/Y0vXA=; b=Cn/rSOEP7zHjZN6aPK6ohZM8UZQ9ju5ZxoglOa7JEsUEzKYQonxXft+teBZdpwBMsz g034feQqQ1RagxAG8H1ak05gOtke3C9slA4KQ+dh5gsEWuShvEgeV/bhEBHySNF6pyiW uI6jjvltziAFG0Yg81r7cC3xn6nir5PvBTPrDHe00R6cvKBFsQLhFPMgNdMclCTUQtVD psnnaoMgK6m2qVaTsOHB8EiPH2AEwy40iYQji4EyiJTTxDIiyvsTIiI/5zrqh6yIuZ6y WIdrnpi762ZJRVZWnulaQzRK3PEjJ9XOIan8lUgNX8wazI4Nisrmv1a3cdbcWMWmS8oU Astg== X-Gm-Message-State: APjAAAUKyBq9luBTUWSP8i9y2dcdZ6SaAMImW1n6BWI5ApcXLoD5vIcg AXrUsVYwsPI5pQAywg3OInXmndSeZxt7h52cYxHYJQ== X-Received: by 2002:a9d:8d2:: with SMTP id 76mr25447839otf.17.1574777192640; Tue, 26 Nov 2019 06:06:32 -0800 (PST) MIME-Version: 1.0 References: <20191126114121.85552-1-elver@google.com> <20191126122917.GA37833@lakrids.cambridge.arm.com> In-Reply-To: <20191126122917.GA37833@lakrids.cambridge.arm.com> From: Marco Elver Date: Tue, 26 Nov 2019 15:06:21 +0100 Message-ID: Subject: Re: [PATCH v2 1/3] asm-generic/atomic: Use __always_inline for pure wrappers To: Mark Rutland Cc: Will Deacon , Peter Zijlstra , Boqun Feng , Arnd Bergmann , Dmitry Vyukov , LKML , linux-arch , kasan-dev , "Paul E. McKenney" , Randy Dunlap Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 26 Nov 2019 at 13:29, Mark Rutland wrote: > > On Tue, Nov 26, 2019 at 12:41:19PM +0100, Marco Elver wrote: > > Prefer __always_inline for atomic wrappers. When building for size > > (CC_OPTIMIZE_FOR_SIZE), some compilers appear to be less inclined to > > inline even relatively small static inline functions that are assumed to > > be inlinable such as atomic ops. This can cause problems, for example in > > UACCESS regions. > > > > By using __always_inline, we let the real implementation and not the > > wrapper determine the final inlining preference. > > > > For x86 tinyconfig we observe: > > - vmlinux baseline: 1316204 > > - vmlinux with patch: 1315988 (-216 bytes) > > > > This came up when addressing UACCESS warnings with CC_OPTIMIZE_FOR_SIZE > > in the KCSAN runtime: > > http://lkml.kernel.org/r/58708908-84a0-0a81-a836-ad97e33dbb62@infradead.org > > > > Reported-by: Randy Dunlap > > Signed-off-by: Marco Elver > > --- > > v2: > > * Add missing '#include ' > > * Add size diff to commit message. > > > > v1: http://lkml.kernel.org/r/20191122154221.247680-1-elver@google.com > > --- > > include/asm-generic/atomic-instrumented.h | 335 +++++++++++----------- > > include/asm-generic/atomic-long.h | 331 ++++++++++----------- > > scripts/atomic/gen-atomic-instrumented.sh | 7 +- > > scripts/atomic/gen-atomic-long.sh | 3 +- > > 4 files changed, 340 insertions(+), 336 deletions(-) > > > diff --git a/scripts/atomic/gen-atomic-instrumented.sh b/scripts/atomic/gen-atomic-instrumented.sh > > index 8b8b2a6f8d68..86d27252b988 100755 > > --- a/scripts/atomic/gen-atomic-instrumented.sh > > +++ b/scripts/atomic/gen-atomic-instrumented.sh > > @@ -84,7 +84,7 @@ gen_proto_order_variant() > > [ ! -z "${guard}" ] && printf "#if ${guard}\n" > > > > cat < > -static inline ${ret} > > +static __always_inline ${ret} > > ${atomicname}(${params}) > > { > > ${checks} > > @@ -146,17 +146,18 @@ cat << EOF > > #ifndef _ASM_GENERIC_ATOMIC_INSTRUMENTED_H > > #define _ASM_GENERIC_ATOMIC_INSTRUMENTED_H > > > > +#include > > #include > > Sorry for the (super) trivial nit, but could you please re-order these > two alphabetically, i.e. > > #include > #include > > With that: > > Acked-by: Mark Rutland Done, thanks for the acks! v3: http://lkml.kernel.org/r/20191126140406.164870-1-elver@google.com > [...] > > > @@ -64,6 +64,7 @@ cat << EOF > > #ifndef _ASM_GENERIC_ATOMIC_LONG_H > > #define _ASM_GENERIC_ATOMIC_LONG_H > > > > +#include > > #include > > Unlike the above, this doesn't need to be re-ordered; for whatever > reason, linux/* includes typically come before asm/* includes. > > Thanks, > Mark.