Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp8987792ybi; Tue, 23 Jul 2019 19:32:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqzhMDp1/cE1I1T20JDw1XKPNb91jRQSVi7pLQvVE9c2qoWobkOoCjelre6sGgjE1a2hIkEc X-Received: by 2002:a17:902:76c7:: with SMTP id j7mr80895394plt.247.1563935534947; Tue, 23 Jul 2019 19:32:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563935534; cv=none; d=google.com; s=arc-20160816; b=Esx5iwD2uqLBNqGglGiViE4E96vjeg2iJK4FDlWcLmTirg3EfoK9V2WAkWUHGWxdLj pJE4++jyFuX0bBo57BI38pwOVAU5USyb8dtAes86WUupEEAEda/ma4nx3UAc2fVUQ4ID X8p3A+D2reUNHA65zrmycWtCmTMdd0ycSF57fOL9fX3E65Fs1290079ZmheQ7weUOjf1 Gh6taYzoM9esBnQ0nTof1NM+mFsZ0BKExbihAz4RgXwk8vYQfXHmOaT/yaDtKZnUgfo1 fv9QVEC3lR0m0YR/wPlT9WTE45DmRqSyrzLC9sHMxxunCS2YCtDPzY5Hm+FTRfFPhZZE zd3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :dlp-reaction:dlp-version:dlp-product:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from; bh=kRd/rZBi9DsbtBLYNCrsjgaCbzUkTsRzdpyrYVUGwYo=; b=tBAX1v0vCj1ux+SzJOKt3eCI33YbccBk2r+NYiYbbNbA0SqcKuFNQhmK7JkJ1HLbDR PJcUhe+X2w/o9O3uZMm7yHYgU/RXCTG0U+RISGB+2D36V3oXs2LN9YRVsxETCMjlcLvp 9huFYFODulxZ/17TPo4BVPli0bL8qn72/QrKljCrUYfyCMV7vm+l6IOs3q4A5+EndZ/e elWT/ziZYdu0cInxZMh9EoG0CycnEUlmfanyRw+juyMFzSz/3/STMbde1o6qIpwV6CRK N2knWqyFbZsrIPMgItQo1cNQiv7sGCz0NpwpBzucrdpN97E9BWvnLV14G5GySj6RRhv8 hhLw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1si11946760pli.151.2019.07.23.19.31.58; Tue, 23 Jul 2019 19:32:14 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391883AbfGWUtz convert rfc822-to-8bit (ORCPT + 99 others); Tue, 23 Jul 2019 16:49:55 -0400 Received: from mga02.intel.com ([134.134.136.20]:40768 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730760AbfGWUty (ORCPT ); Tue, 23 Jul 2019 16:49:54 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2019 13:49:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,300,1559545200"; d="scan'208";a="174659991" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga006.jf.intel.com with ESMTP; 23 Jul 2019 13:49:53 -0700 Received: from orsmsx126.amr.corp.intel.com (10.22.240.126) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 23 Jul 2019 13:49:53 -0700 Received: from orsmsx110.amr.corp.intel.com ([169.254.10.211]) by ORSMSX126.amr.corp.intel.com ([169.254.4.77]) with mapi id 14.03.0439.000; Tue, 23 Jul 2019 13:49:53 -0700 From: "Moore, Robert" To: Qian Cai , Nick Desaulniers CC: "Wysocki, Rafael J" , "Schmauss, Erik" , "jkim@freebsd.org" , Len Brown , "linux-acpi@vger.kernel.org" , "devel@acpica.org" , clang-built-linux , LKML Subject: RE: [PATCH] acpica: fix -Wnull-pointer-arithmetic warnings Thread-Topic: [PATCH] acpica: fix -Wnull-pointer-arithmetic warnings Thread-Index: AQHVPFEYIycQ0k5IUUyXy4NqYzTqpqbP0wgAgAAvDoCACLPGAA== Date: Tue, 23 Jul 2019 20:49:52 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E3B9661869@ORSMSX110.amr.corp.intel.com> References: <20190717033807.1207-1-cai@lca.pw> <73A4565B-837B-4E13-8B72-63F69BF408E7@lca.pw> In-Reply-To: <73A4565B-837B-4E13-8B72-63F69BF408E7@lca.pw> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYWEwZGI5NTgtYTE0NC00ZWFjLWJjMDYtYjIyYWY5MmFhOTQ1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiY2pvUjE2Mm1qbUl2ejllMmdwQVwvejNWcEJib1RyQ2JUb2Q3R2dnRk14VXo0QVhuUUMrdjJmZUtiSjhJM2dTVTIifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org -----Original Message----- From: Qian Cai [mailto:cai@lca.pw] Sent: Wednesday, July 17, 2019 5:50 PM To: Nick Desaulniers Cc: Wysocki, Rafael J ; Moore, Robert ; Schmauss, Erik ; jkim@freebsd.org; Len Brown ; linux-acpi@vger.kernel.org; devel@acpica.org; clang-built-linux ; LKML Subject: Re: [PATCH] acpica: fix -Wnull-pointer-arithmetic warnings > On Jul 17, 2019, at 6:01 PM, Nick Desaulniers wrote: > > On Tue, Jul 16, 2019 at 8:38 PM Qian Cai wrote: >> >> Clang generate quite a few of those warnings. >> >> drivers/acpi/scan.c:759:28: warning: arithmetic on a null pointer >> treated as a cast from integer to pointer is a GNU extension >> [-Wnull-pointer-arithmetic] >> status = acpi_get_handle(ACPI_ROOT_OBJECT, >> obj->string.pointer, >> ^~~~~~~~~~~~~~~~ >> ./include/acpi/actypes.h:458:56: note: expanded from macro >> 'ACPI_ROOT_OBJECT' >> #define ACPI_ROOT_OBJECT ((acpi_handle) ACPI_TO_POINTER >> (ACPI_MAX_PTR)) >> >> ^~~~~~~~~~~~~~~ >> ./include/acpi/actypes.h:509:41: note: expanded from macro >> 'ACPI_TO_POINTER' >> #define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void *) 0, >> (acpi_size) (i)) >> >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> ./include/acpi/actypes.h:503:84: note: expanded from macro >> 'ACPI_ADD_PTR' >> #define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t, >> (ACPI_CAST_PTR (u8, (a)) + (acpi_size)(b))) >> ^~~~~~~~~~~~~~~~~ >> ./include/acpi/actypes.h:501:66: note: expanded from macro >> 'ACPI_CAST_PTR' >> #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p)) >> ^ >> This is because pointer arithmetic on a pointer not pointing to an >> array is an undefined behavior. Fix it by doing an integer arithmetic >> instead. > > Hi Qian, thanks for the patch. How do I reproduce this issue, > precisely? I just tried: > $ make CC=clang -j71 drivers/acpi/scan.o on linux-next today and don't > observe the warning. My clang is ToT built sometime this week. It > looks like drivers/acpi/scan.o when CONFIG_ACPI=y, which is set in the > defconfig. Is there another set of configs to enable to observe the > warning? # make W=1 -j 256 With the config, https://raw.githubusercontent.com/cailca/linux-mm/master/arm64.config > > Also, the fix is curious. Arithmetic on pointers to different > "objects" (with one element passed the end) may lead to provence > issues due to undefined behavior, but I would have expected some cases > to uintptr_t, then arithmetic on that type, as the solution (which is > what I suspect ACPI_CAST_PTR is doing). > > Further, you seem to have modified ACPI_ADD_PTR but not ACPI_SUB_PTR; > I would have expected both to be afflicted together or not at all > based on their existing implementations. Yes, I thought about that, but ACPI_SUB_PTR does not seem used anywhere, so I thought maybe just start a new discussion to remove it all together later. ACPI_SUB_PTR is used in the iasl data table compiler. > >> >> Signed-off-by: Qian Cai >> --- >> include/acpi/actypes.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index >> ad6892a24015..25b4a32da177 100644 >> --- a/include/acpi/actypes.h >> +++ b/include/acpi/actypes.h >> @@ -500,13 +500,13 @@ typedef u64 acpi_integer; >> >> #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p)) >> #define ACPI_CAST_INDIRECT_PTR(t, p) ((t **) (acpi_uintptr_t) (p)) >> -#define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t, (ACPI_CAST_PTR (u8, (a)) + (acpi_size)(b))) >> +#define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t, (a) + (acpi_size)(b)) We have some questions concerning this change. If (a) is not cast to a u8, the addition will be in whatever units are appropriate for (a) i.e., the type of (a). However, we want ACPI_ADD_PTR (And ACPI_SUB_PTR) to simply perform a byte addition or subtraction - thus the cast to u8. I believe that is the original thinking behind the macros. >> #define ACPI_SUB_PTR(t, a, b) ACPI_CAST_PTR (t, (ACPI_CAST_PTR (u8, (a)) - (acpi_size)(b))) >> #define ACPI_PTR_DIFF(a, b) ((acpi_size) (ACPI_CAST_PTR (u8, (a)) - ACPI_CAST_PTR (u8, (b)))) >> >> /* Pointer/Integer type conversions */ >> >> -#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void *) 0, (acpi_size) (i)) >> +#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, 0, (acpi_size) (i)) > > IIUC, these are adding `i` to NULL (or (void*)0)? X + 0 == X ? > -- > Thanks, > ~Nick Desaulniers