Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2249692pxb; Sun, 17 Oct 2021 09:37:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyJuX9Olf9clmgeBEpSZuWMn/R0N/D3uahqeNTvK1IgxRjlQJhbkOYe7dBdhDz+UvGdqNZR X-Received: by 2002:a05:6a00:2410:b0:409:5fbd:cb40 with SMTP id z16-20020a056a00241000b004095fbdcb40mr24042760pfh.8.1634488654338; Sun, 17 Oct 2021 09:37:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634488654; cv=none; d=google.com; s=arc-20160816; b=oclcoodsk9cZeYFNa3dNk2pF5j242LbgGKKi+qFxobgVbTPi32boOo8rrGboOqUxJg fCJHcp2rMXjKmMHNvTK2seUedhC9Ylmb4lHzRFJkQMP9BuCGPUdNZihdK4DxZtZxdHXF L75hCAUGY/O3EeWuqqwIkxt/Hj2fGNAwlb11n4MWfQObfMYP7Ok9M/W9KcbENPtMog9j 7RVJYTYY3Trye3U38U5omtbI9rDV3mm2vNUC+FsNQv459XOuOUTskmWIVIUeU35TROeU Q5P9FbBNWt6Di9naugBufjvw6yDilvew9Je+29tzIPMBg2oQmmLF6LTg7N/l6gUmtq5t ILbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=nJ0THKXxd/Bt+ZOJhojuTzHMSTcdTYp1X+BGRWm6h4g=; b=zRfjLm+fuN0NM1EzVwsk9tUi68YDfNsZCw4qCsfuMT324oFfVE9ASb/VYpPpXhEVR/ Xm8/kbrrakknGs87WAFDq9gmqDXjusJT4zhJiK1Qqd5lvIZzZGDndN+1uidDCdnRSm3l fXkuPMe3w67gAB2cy9k7EWcbOqDwZY0PynweGXSRxTWdKFw4BszHAfHsbBmGArp8u7tY srC94x4pEofTCK4F34mi4U8+QzJQAXd5joHAURmnm43wfhJ+GqINPDd17W1nIQMCaPtu bnuskmeKv/DhV6I3+taRSO1sM5wNec5zf/OUMkGWwjt5fyumaKtDbZUjv8RHtzkLbU0p 4fHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=AmJt9r5W; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b="Av/zrPQ9"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k7si23539290pjj.5.2021.10.17.09.37.10; Sun, 17 Oct 2021 09:37:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=AmJt9r5W; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b="Av/zrPQ9"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242425AbhJOR7j (ORCPT + 99 others); Fri, 15 Oct 2021 13:59:39 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:51734 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237652AbhJOR7i (ORCPT ); Fri, 15 Oct 2021 13:59:38 -0400 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1634320650; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nJ0THKXxd/Bt+ZOJhojuTzHMSTcdTYp1X+BGRWm6h4g=; b=AmJt9r5Wubqb7bqcK7HDmhMVd2IlIBGgmSCKDUp5K/5o5V6Uh/oRsuJPA9R+z3eKwJTuPj cbr/jHp9zoRYrsH05O2ABxTbz/ygz9YHb2Ldy4/xiuCYkD+9/BpE48QjLMHEKjTbby/gXr ZDqzXr8mnDn6+yf7dkpBrdEPRBzHpg7szyQL+VEwzWdV0kfMfeXLPZDPkW1xYDQLiXrT1k g4ExYzVi/cyrGEcMw3QAErKB2sAdsdLUaKkra411yZ+B30sEqcRuaXEojh1k7wzOT1Ke/L RM+BzrACLxY9/aN7DICkUA94TM70plzX4NiUXtv5+l6k8hn8gn25dzTbQ3DcwQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1634320650; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nJ0THKXxd/Bt+ZOJhojuTzHMSTcdTYp1X+BGRWm6h4g=; b=Av/zrPQ98wmRxY7Yh8H4q2ZJOvvECSItHXiAM1Did8Vc8w8w8mFy8UkB5thu3zMMUloM0h 6LVOlDPSdTb2C4Dg== To: Andy Lutomirski , Sami Tolvanen , the arch/x86 maintainers Cc: Kees Cook , Josh Poimboeuf , "Peter Zijlstra (Intel)" , Nathan Chancellor , Nick Desaulniers , Sedat Dilek , Steven Rostedt , linux-hardening@vger.kernel.org, Linux Kernel Mailing List , llvm@lists.linux.dev Subject: Re: [PATCH v5 03/15] linkage: Add DECLARE_NOT_CALLED_FROM_C In-Reply-To: <8735p25llh.ffs@tglx> References: <20211013181658.1020262-1-samitolvanen@google.com> <20211013181658.1020262-4-samitolvanen@google.com> <7377e6b9-7130-4c20-a0c8-16de4620c995@www.fastmail.com> <8735p25llh.ffs@tglx> Date: Fri, 15 Oct 2021 19:57:30 +0200 Message-ID: <87zgra41dh.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 15 2021 at 17:55, Thomas Gleixner wrote: > On Thu, Oct 14 2021 at 19:51, Andy Lutomirski wrote: >> On Wed, Oct 13, 2021, at 11:16 AM, Sami Tolvanen wrote: > That still tells me: > > 1) This is a function > > 2) It has a regular argument which is expected to be in RDI > > which even allows to do analyis of e.g. the alternative call which > invokes that function. > > DECLARE_NOT_CALLED_FROM_C(clear_page_erms); > > loses these properties and IMO it's a tasteless hack. Look: SYSCALL_DEFINE2(set_robust_list, struct robust_list_head __user *, head, size_t, len) Not beautiful, but it gives the information which is needed and it tells me clearly what this is about. While the above lumps everything together whatever it is. Having __bikeshedme would allow to do: __hardware_call __xenhv_call __inline_asm_call or such, which clearly tells how the function should be used and it can even be validated by tooling. You could to that with macros as well, but thats not what you offered. Seriously, if you want to sell me that stuff, then you really should offer me something which has a value on its own and makes it palatable to me. That's not something new. See: https://lore.kernel.org/lkml/alpine.LFD.2.00.1001251002430.3574@localhost.localdomain/ That said, I still want to have a coherent technical explanation why the compiler people cannot come up with a sensible annotation for these things. I'm tired of this attitude, that they add features and then ask us to make our code more ugly. It's not a well hidden secret that the kernel uses these kind of constructs. So why on earth can't they be bothered to think about these things upfront and offer us something nice and useful? Thanks, tglx