Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp4738196pxb; Tue, 5 Oct 2021 09:17:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwjvOEAXueW7OeyAqUSo1IWOohaQjEO7bNqljYjh9p+ssFS1ExtFtBrQ1gUe8AaSIUj7IjA X-Received: by 2002:a17:906:884:: with SMTP id n4mr24615962eje.54.1633450659705; Tue, 05 Oct 2021 09:17:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633450659; cv=none; d=google.com; s=arc-20160816; b=mgJ5mtax21sTXfCc6n1WFNydEC8nTIJy/5vcJDvFleG+HHGSlpWkDBGN6lDrN5VL1y CXiF62rDSysEa2v9G0+sqzHnIsGrAYoFsATsr0nS+iIg6GD4ghLcpi1XaTJnlEUAyURt LD2Agj66RztnDv9kIqy8ICSq63lfvwY03CKiEBLRBSkauF/9AGk1pBuTQDbLAU9jtUJ9 ge6te0de+2SjUngFL87fddgKwgXct+fgNHHs3rXCtUkizmjBYQy13lr/ZzbCi8rA2r7+ MHH5RCZm4L6pCe75JQeOFOgj5rMejiPm72OkdBC6KLiP3CuSV+a3WVmAn71bCuCNxIIm Co7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:dkim-signature:dkim-filter; bh=wdXI//wKXjJYzeAAdexY7E9PnkR6DLjHJxcq7rpw10M=; b=ee/zHNMxSxkTMa4G4uIJLvjaOnNgJvRivfCW+fjLuuokkhfTmKf0vn393TE+/EgEq8 AvFXdEkw0lhmo11CukpuE41+gOYSvo1Cf5HvaaCzQIVFscqkLRLQf6Yg8n7VUrvMXDcZ A+FP34juh5t51pU7S2yUSAimz1YoAsBQ5UnmmZPRgm+1u83t/GpUXd0NCOEN2uYE+BRc CcB01+YkitH/DIr0WOSh/M38QryR7EHKPXHu0nShZqxRAqcS16VDkeFs/vxSTV4b0+7A rJzqF1DAUTmeFBNPYKhUmMPJ9abzKC/4EM+NCh0Hdi6yMvzqfhpXpfOuXT9zxpV6JlM+ reuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=M4xcmPCu; 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=NONE dis=NONE) header.from=efficios.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c11si2940237edw.382.2021.10.05.09.17.13; Tue, 05 Oct 2021 09:17:39 -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=@efficios.com header.s=default header.b=M4xcmPCu; 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=NONE dis=NONE) header.from=efficios.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236440AbhJEQQ5 (ORCPT + 99 others); Tue, 5 Oct 2021 12:16:57 -0400 Received: from mail.efficios.com ([167.114.26.124]:48222 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236419AbhJEQQ4 (ORCPT ); Tue, 5 Oct 2021 12:16:56 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 1606838E466; Tue, 5 Oct 2021 12:15:05 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id m0Qvt7WXiQiC; Tue, 5 Oct 2021 12:15:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 748AD38E780; Tue, 5 Oct 2021 12:15:04 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 748AD38E780 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1633450504; bh=wdXI//wKXjJYzeAAdexY7E9PnkR6DLjHJxcq7rpw10M=; h=Date:From:To:Message-ID:MIME-Version; b=M4xcmPCu9QQijyxoeSD7mQnm/miHc6NnbsFQ4tWPe0I66PpgBDxrH9mbSnGBOpJMi +bj1V51Nqw29OTYPj5Ry0lmmj4S6bT69I6PQsawkruFuEnW3OKhFTf/xXx/APCaoHA jVhORbMm9RPSv2bAjZT0i3xBhXqlJ7S6s2ssnCkX1+zTUQXPRgfJEPX95W8kagv1Rq o+G3kyphfZis+HmS6DOU4P3bC979jwKMF+mk3yZd+eqbqUAFDTaBWfBRuy1EazPVcq de6GgD0LKY0hKYEK8qOL/rYH5wW6MJ0tiDqZdUjeBwfg8MRIqymzjKl2N3bmAVPAGu PYXYKFD659Aog== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZC9KUwjnWQxC; Tue, 5 Oct 2021 12:15:04 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 5DACE38E2F5; Tue, 5 Oct 2021 12:15:04 -0400 (EDT) Date: Tue, 5 Oct 2021 12:15:04 -0400 (EDT) From: Mathieu Desnoyers To: rostedt Cc: linux-kernel , Linus Torvalds , Paul , Josh Triplett , Lai Jiangshan , "Joel Fernandes, Google" , Pablo Neira Ayuso , Jozsef Kadlecsik , Florian Westphal , "David S. Miller" , Hideaki YOSHIFUJI , David Ahern , Jakub Kicinski , rcu , netfilter-devel , coreteam , netdev Message-ID: <155148572.2789.1633450504238.JavaMail.zimbra@efficios.com> In-Reply-To: <20211005115817.2e1b57bd@gandalf.local.home> References: <20211005094728.203ecef2@gandalf.local.home> <505004021.2637.1633446912223.JavaMail.zimbra@efficios.com> <20211005115817.2e1b57bd@gandalf.local.home> Subject: Re: [RFC][PATCH] rcu: Use typeof(p) instead of typeof(*p) * MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_4156 (ZimbraWebClient - FF92 (Linux)/8.8.15_GA_4156) Thread-Topic: Use typeof(p) instead of typeof(*p) * Thread-Index: DIGMOxZGUFfMiJjhKijLQjQDGvVFOA== Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Oct 5, 2021, at 11:58 AM, rostedt rostedt@goodmis.org wrote: > On Tue, 5 Oct 2021 11:15:12 -0400 (EDT) > Mathieu Desnoyers wrote: > >> ----- On Oct 5, 2021, at 9:47 AM, rostedt rostedt@goodmis.org wrote: >> [...] >> > #define rcu_dereference_raw(p) \ >> > ({ \ >> > /* Dependency order vs. p above. */ \ >> > typeof(p) ________p1 = READ_ONCE(p); \ >> > - ((typeof(*p) __force __kernel *)(________p1)); \ >> > + ((typeof(p) __force __kernel)(________p1)); \ >> > }) >> >> AFAIU doing so removes validation that @p is indeed a pointer, so a user might >> mistakenly >> try to use rcu_dereference() on an integer, and get away with it. I'm not sure >> we want to >> loosen this check. I wonder if there might be another way to achieve the same >> check without >> requiring the structure to be declared, e.g. with __builtin_types_compatible_p ? > > Is that really an issue? Because you would be assigning it to an integer. > > > x = rcu_dereference_raw(y); > > And that just makes 'x' a copy of 'y' and not really a reference to it, thus > if you don't have a pointer, it's just a fancy READ_ONCE(y). See Documentation/RCU/arrayRCU.rst: "It might be tempting to consider use of RCU to instead protect the index into an array, however, this use case is **not** supported. The problem with RCU-protected indexes into arrays is that compilers can play way too many optimization games with integers, which means that the rules governing handling of these indexes are far more trouble than they are worth. If RCU-protected indexes into arrays prove to be particularly valuable (which they have not thus far), explicit cooperation from the compiler will be required to permit them to be safely used." So AFAIU validation that rcu_dereference receives a pointer as parameter is done on purpose. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com