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 X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A1EAC18E00 for ; Wed, 19 Feb 2020 19:11:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0543B208C4 for ; Wed, 19 Feb 2020 19:11:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="jcMcqCD/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0543B208C4 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A6B816B0003; Wed, 19 Feb 2020 14:11:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A1D216B0006; Wed, 19 Feb 2020 14:11:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 932906B0007; Wed, 19 Feb 2020 14:11:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7BCCB6B0003 for ; Wed, 19 Feb 2020 14:11:32 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3ACB382499B9 for ; Wed, 19 Feb 2020 19:11:32 +0000 (UTC) X-FDA: 76507820424.16.leaf95_4790008efed1b X-HE-Tag: leaf95_4790008efed1b X-Filterd-Recvd-Size: 5249 Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Wed, 19 Feb 2020 19:11:31 +0000 (UTC) Received: by mail-pl1-f196.google.com with SMTP id ay11so468340plb.0 for ; Wed, 19 Feb 2020 11:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ap2ctb13s1qbCfj4OTZiKRJIdNv9n1BdWeqlAwLw5Qg=; b=jcMcqCD/4wwPKW1BHPXI7rg577Xt5FZSRtafy05KYiATgkZDsr7BgHYLd+lGSHb+2C AVZ1aC8O25vV/DHzCNwchjAmiG2WZZSFwCt67Fss+0OVrlHba21K+6IYAmYgzxUEROYY xwtbemqIexJTa2NGIKygqTcwTw1znjQKZdY4IZ0gvY5dqKodKNQiEpLqmO2PqWCrCPI7 L8qWqe5AKFU8sS3MtQoI9Bio+svQB7yq+GigZmKlYGHQGbQ2PyYxy+BA7zf+/MDJpvRB BLUNm/M8cExRUuK8PLQc7v9m1dAdNezOvibNmKaxQVKVl0l6e/DrLcgOyG/XsKgbabxP KLiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ap2ctb13s1qbCfj4OTZiKRJIdNv9n1BdWeqlAwLw5Qg=; b=l4I3Yvb01OnbNO/F27S9AEEuz5f8glR4ca8lW/2S5C/GRw/k4Y5cZmwWuajvqMB6oD L50kKF0nbBondZPF2bH3+q/hYCAQKIQ52L8w+ifLmMouDXpblFus5TagA0X9z5KuUy1W qmrKWrSS6Bg3fhzBDaT+EN91/fwKv3S0pogpqSKbKfTXIusTlGkAHIYR47SrxctAbmy0 fj2XSqNRA4Gew0zoIimdRd8J4Lp3HwHYEF5pkd819TcPT3MOvNvrjcK3uXi6mgq1lvQm QGSYNykrgueW8wxmwWSQbT+2s//6CJ8FBimPeF5wITVDj/TKlkYAEYQiB9M0RSKsCAjN k7tA== X-Gm-Message-State: APjAAAWlVN/YzgjY6hNWC7Ta4xtS3zSZ4LzPQZSme3ZFbhdk3/lIJfsV smkwqf68VUSNGg48X1DZwQLEa7U5n2t/Zxu9+7T+GQ== X-Google-Smtp-Source: APXvYqztPgBIuE+BF1ZFh+oiIEmClwhAkgolIs71KHBbWVvRtiGt0/phNlarS8Hv9uDQY15pC7dm7FoVZLJyzFQZaQA= X-Received: by 2002:a17:90a:3745:: with SMTP id u63mr10347452pjb.123.1582139490281; Wed, 19 Feb 2020 11:11:30 -0800 (PST) MIME-Version: 1.0 References: <20200219045423.54190-1-natechancellor@gmail.com> <20200219045423.54190-4-natechancellor@gmail.com> <20200219093445.386f1c09@gandalf.local.home> <20200219181619.GV31668@ziepe.ca> In-Reply-To: <20200219181619.GV31668@ziepe.ca> From: Nick Desaulniers Date: Wed, 19 Feb 2020 11:11:19 -0800 Message-ID: Subject: Re: [PATCH 3/6] tracing: Wrap section comparison in tracer_alloc_buffers with COMPARE_SECTIONS To: Jason Gunthorpe , Nathan Chancellor Cc: Steven Rostedt , Masahiro Yamada , Michal Marek , Arnd Bergmann , Ingo Molnar , Jason Baron , Catalin Marinas , Andrew Morton , LKML , Linux Kbuild mailing list , linux-arch , Linux Memory Management List , clang-built-linux Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Feb 19, 2020 at 10:16 AM Jason Gunthorpe wrote: > > On Wed, Feb 19, 2020 at 09:44:31AM -0800, Nick Desaulniers wrote: > > Hey Nathan, > > Thanks for the series; enabling the warning will help us find more > > bugs. Revisiting what the warning is about, I checked on this > > "referring to symbols defined in linker scripts from C" pattern. This > > document [0] (by no means definitive, but I think it has a good idea) > > says: > > > > Linker symbols that represent a data address: In C code, declare the > > variable as an extern variable. Then, refer to the value of the linker > > symbol using the & operator. Because the variable is at a valid data > > address, we know that a data pointer can represent the value. > > Linker symbols for an arbitrary address: In C code, declare this as an > > extern symbol. The type does not matter. If you are using GCC > > extensions, declare it as "extern void". > > > > Indeed, it seems that Clang is happier with that pattern: > > https://godbolt.org/z/sW3t5W > > > > Looking at __stop___trace_bprintk_fmt in particular: > > > > kernel/trace/trace.h > > 1923:extern const char *__stop___trace_bprintk_fmt[]; > > Godbolt says clang is happy if it is written as: > > if (&__stop___trace_bprintk_fmt[0] != &__start___trace_bprintk_fmt[0]) > > Which is probably the best compromise. The type here is const char > *[], so it would be a shame to see it go. If the "address" is never dereferenced, but only used for arithmetic (in a way that the the pointed to type is irrelevant), does the pointed to type matter? I don't feel strongly either way, but we seem to have found two additional possible solutions for these warnings, which is my ultimate goal. Nathan, hopefully those are some ideas you can work with to address the additional cases throughout the kernel? -- Thanks, ~Nick Desaulniers