Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp536479pxb; Wed, 18 Nov 2020 10:34:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJzuzoIKsb1NA1+SDs0kInX0ttuDFx3y/eBfqQ+4yp/vWJO37YBJWgOvGyC4d4jCJ2qPsdPN X-Received: by 2002:a05:6402:1b19:: with SMTP id by25mr27065359edb.108.1605724466350; Wed, 18 Nov 2020 10:34:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605724466; cv=none; d=google.com; s=arc-20160816; b=YabMtmXwwDFLLCBWfZDPl4PZgQQGP3Dm1HNnd+HqQwC3RhHtVMPIcM/EV5t3q/HpVE TnAJ+4d4ySQIm1wREGimqwJyj45TJGXPlo7g+2HuWdiytHrCxH5K5Q7W/NFG8aObnYMa UBKJ+quV5QzhVXcld5dBkTtImPnMBHmxOYO7TzAR6m8QPd6N72j0Dk/df9nDGgTI40fo vnZdnPVbbzGe1EFQc9M89nbbi74IWzMpo7i3brsJNW+vmlp1fZAoGd726vm8fJjfnDTA WbYzsgzLOyBQKxxd/keGvzhhpthcCGjtYzImpi9S93Jxqkpw7XZD94tUGQmN7ED9JNMv H0tg== 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:in-reply-to:date :references:subject:cc:to:from; bh=pfu+Dv19g8KYd5aboXR5AlRX/Nn9G7Woi2S5v+W9ZGc=; b=Xs7oipPcqh9nF7bQnBTQ9lumeGjs9zyQg75uFyG+Ctxa9VhfnZ98YEMP21i2o/Rved WN00EJ3Jj+yFXR7GenK/5uhYYz/nsGsGJ3No1nt1cyd4VljH3ll5qcm8Z85ssiooBYPN OYYSe2FfdryOR9JQa3AOLyt/jIk0o1tH0CgLI0N32HDvW7DUQethWC8bYFsTjW7zOTuh XeAp6w9M273xrL4dBvi2LTGqgGX9dGXpGn/0Mqi7YKwCql0zhLPWKUF2Jrwb4eVkgCLi nUAom8X/LrKUUwWUUJFsma0Uzv+8qrAFvJDYERg48awsAoqHdA8xZ42oL3rBe3CFXoOh d1vg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t17si16538052edq.418.2020.11.18.10.33.59; Wed, 18 Nov 2020 10:34:26 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726780AbgKRScW (ORCPT + 99 others); Wed, 18 Nov 2020 13:32:22 -0500 Received: from albireo.enyo.de ([37.24.231.21]:43476 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726629AbgKRScV (ORCPT ); Wed, 18 Nov 2020 13:32:21 -0500 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1kfSFC-0006nX-JX; Wed, 18 Nov 2020 18:31:50 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1kfSFC-0005cN-Gh; Wed, 18 Nov 2020 19:31:50 +0100 From: Florian Weimer To: Segher Boessenkool Cc: Steven Rostedt , Nick Desaulniers , Peter Zijlstra , Sami Tolvanen , Mathieu Desnoyers , linux-kernel , Matt Mullins , Ingo Molnar , Alexei Starovoitov , Daniel Borkmann , Dmitry Vyukov , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , John Fastabend , KP Singh , netdev , bpf , Kees Cook , Josh Poimboeuf , linux-toolchains@vger.kernel.org Subject: Re: violating function pointer signature References: <20201116175107.02db396d@gandalf.local.home> <47463878.48157.1605640510560.JavaMail.zimbra@efficios.com> <20201117142145.43194f1a@gandalf.local.home> <375636043.48251.1605642440621.JavaMail.zimbra@efficios.com> <20201117153451.3015c5c9@gandalf.local.home> <20201118132136.GJ3121378@hirez.programming.kicks-ass.net> <20201118121730.12ee645b@gandalf.local.home> <20201118181226.GK2672@gate.crashing.org> Date: Wed, 18 Nov 2020 19:31:50 +0100 In-Reply-To: <20201118181226.GK2672@gate.crashing.org> (Segher Boessenkool's message of "Wed, 18 Nov 2020 12:12:26 -0600") Message-ID: <87o8jutt2h.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Segher Boessenkool: > On Wed, Nov 18, 2020 at 12:17:30PM -0500, Steven Rostedt wrote: >> I could change the stub from (void) to () if that would be better. > > Don't? In a function definition they mean exactly the same thing (and > the kernel uses (void) everywhere else, which many people find clearer). And I think () functions expected a caller-provided parameter save area on powerpc64le, while (void) functions do not. It does not matter for an empty function, but GCC prefers to use the parameter save area instead of setting up a stack frame if it is present. So you get stack corruption if you call a () function as a (void) function. (The other way round is fine.)