From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0DB43CD6134 for ; Tue, 10 Oct 2023 09:54:50 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.614647.955856 (Exim 4.92) (envelope-from ) id 1qq9Rb-0008PB-HP; Tue, 10 Oct 2023 09:54:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 614647.955856; Tue, 10 Oct 2023 09:54:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qq9Rb-0008P4-E3; Tue, 10 Oct 2023 09:54:27 +0000 Received: by outflank-mailman (input) for mailman id 614647; Tue, 10 Oct 2023 09:54:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qq9Ra-0008Oy-Fp for xen-devel@lists.xenproject.org; Tue, 10 Oct 2023 09:54:26 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fe7cf795-6752-11ee-98d3-6d05b1d4d9a1; Tue, 10 Oct 2023 11:54:25 +0200 (CEST) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 98DB94EE0742; Tue, 10 Oct 2023 11:54:24 +0200 (CEST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fe7cf795-6752-11ee-98d3-6d05b1d4d9a1 MIME-Version: 1.0 Date: Tue, 10 Oct 2023 11:54:24 +0200 From: Nicola Vetrini To: Stefano Stabellini Cc: Julien Grall , xen-devel@lists.xenproject.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, Simone Ballarin , Doug Goldstein , George Dunlap , Wei Liu Subject: Re: [XEN PATCH][for-4.19 1/2] xen: introduce a deviation for Rule 11.9 In-Reply-To: References: <98bc1d90b93856ed7516a19114facf6528120248.1696494834.git.nicola.vetrini@bugseng.com> <605f8045-754d-4d3c-b1b3-3bb34112bfc8@xen.org> <2aafb9710b4754e8d57acc1f769693b4@bugseng.com> User-Agent: Roundcube Webmail/1.4.3 Message-ID: <7168dfb8bcfae953c0d65fe05699ca9b@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 07/10/2023 02:33, Stefano Stabellini wrote: > On Fri, 6 Oct 2023, Julien Grall wrote: >> On 06/10/2023 10:58, Nicola Vetrini wrote: >> > On 06/10/2023 11:27, Julien Grall wrote: >> > > Hi, >> > > >> > > On 05/10/2023 09:45, Nicola Vetrini wrote: >> > > > The constant 0 is used instead of NULL in '__ACCESS_ONCE' as a >> > > > compile-time check to detect non-scalar types; its usage for this >> > > > purpose is documented in rules.rst as an exception. >> > > Documenting ACCESS_ONCE() in rules.rst seems a bit odd. I am guessing >> > > that other analysis tool may point out the same error and therefore it >> > > would seem more appropriate to use a deviation. >> > > >> > > This would also avoid having a specific rule in the Eclair >> > > configuration for __ACCESS_ONCE(). >> > > >> > >> > I figured a single accepted use would benefit from an explicit exclusion. >> > I can rework it to use an in-code comment to deviate, in whatever form that >> > comment may be >> > (still with some bits of ECLAIR-specific configuration anyway, as discussed >> > for R2.1). >> >> I think it would be preferrable to have a deviation in the code. This >> would be >> helpful for other analysis tools. > > Yes exactly, see my reply: > https://marc.info/?l=xen-devel&m=169663696228889 > > I know I acked the patch but I agree with Julien. A deviation as an > in-code comment (SAF-x-safe) is always the best option. If that doesn't > work, we cannot keep adding stuff in the notes section of rules.rst. It > doesn't scale. We should create a new document, like deviations.rst, or > add a new section at the bottom of documenting-violations.rst or > possibly safe.json. I'll rebase this patch with an entry in deviations.rst, so that this applies to staging cleanly. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)