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=-2.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 947ECC34056 for ; Wed, 19 Feb 2020 19:22:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4686A208E4 for ; Wed, 19 Feb 2020 19:22:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JbyfA+6+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4686A208E4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D22AD6B0003; Wed, 19 Feb 2020 14:22:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CD2C56B0006; Wed, 19 Feb 2020 14:22:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE87B6B0007; Wed, 19 Feb 2020 14:22:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0087.hostedemail.com [216.40.44.87]) by kanga.kvack.org (Postfix) with ESMTP id A77596B0003 for ; Wed, 19 Feb 2020 14:22:52 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5BE232DFC for ; Wed, 19 Feb 2020 19:22:52 +0000 (UTC) X-FDA: 76507848984.17.patch61_18ffef0e24f1e X-HE-Tag: patch61_18ffef0e24f1e X-Filterd-Recvd-Size: 6548 Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Wed, 19 Feb 2020 19:22:51 +0000 (UTC) Received: by mail-ot1-f65.google.com with SMTP id 77so1265415oty.6 for ; Wed, 19 Feb 2020 11:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=nGyzNqwmfC+StEGiPL2xQ9nSi3AHwKN4sRF+U5rIpw4=; b=JbyfA+6+JJDbDgo5q7DXJkywgq8p9fWfaHY9hcamDR9TIm1I8w5p0TslUp6LsE340e Li294B0nCtY/sJUUB+3ldTqvUSUPubHJ3Itp3Yjg4K1QLM4bCa9yrMh8WDC7QkcYc55x FVK+j9UdRhw5HtmGQNaLX8F/GtyjcEbFZApN0Ag3jG4VxXN9dIUwvrJOMbtplHukePML zAG1lUuE1Orv/jQfCeiFsv3MwuWcPSH6WqCiE0Tj3bUAPABINb+DsIj0c0qHNlO97jy6 ITSfedy7wCZYK0t3u9u9ENvrs8lXiPtqcCPoQd+DnsxaKpmJnF79JyApAwSvV09bOgDT OJag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=nGyzNqwmfC+StEGiPL2xQ9nSi3AHwKN4sRF+U5rIpw4=; b=arqCy9Cr3NMEDLqyRTUiV0Ci6RYpJgfhCMU4/UV1S6DIAMvBlSRzz33n4N3qmD2Hpy 18Aql0mgKc0KxDPyaJJGPotoZBstdz3AKsQrQ/rE6RSYczagK7t2RTBU658m+Dwbx/wH malmD2s5OPmLF8LHJrJhhvIfgyl7Qt/YTGXsrBYpIxOMP8wGWEK/Jq2mJmGhYjqp6vlL iHn0gL0inotu9sRNGXmzhSMkiXNT8Mm70mZBpJHjN7hIG9Wfmw9LyTjIpjuiMNEL1PvD eWAscBFAczyGvINJD1JbGKwL1w3roCMacLOhyJ0/H9U0iNiOb6ZbjGRcBVEj/b3LQIgh HCmw== X-Gm-Message-State: APjAAAUoCf5KElH+iM1YyUdYZI6di3LQMk+jtFx4UIJg44We5dsZ2FOC Qq40KQrtXi3O0M+a0QxgIuY= X-Google-Smtp-Source: APXvYqxlEJNDcB79lMPiHrXtK79931NtdsnXY6+4CaCPWiQIDJF9SmeBFXKLjspoTxKQ8Ag/rEDtGw== X-Received: by 2002:a9d:6b84:: with SMTP id b4mr20963596otq.190.1582140170892; Wed, 19 Feb 2020 11:22:50 -0800 (PST) Received: from ubuntu-m2-xlarge-x86 ([2604:1380:4111:8b00::1]) by smtp.gmail.com with ESMTPSA id t9sm211166otm.76.2020.02.19.11.22.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 19 Feb 2020 11:22:50 -0800 (PST) Date: Wed, 19 Feb 2020 12:22:49 -0700 From: Nathan Chancellor To: Nick Desaulniers Cc: Jason Gunthorpe , 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 Subject: Re: [PATCH 3/6] tracing: Wrap section comparison in tracer_alloc_buffers with COMPARE_SECTIONS Message-ID: <20200219192249.GA8840@ubuntu-m2-xlarge-x86> References: <20200219045423.54190-1-natechancellor@gmail.com> <20200219045423.54190-4-natechancellor@gmail.com> <20200219093445.386f1c09@gandalf.local.home> <20200219181619.GV31668@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) 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 11:11:19AM -0800, Nick Desaulniers wrote: > 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 Yes, thank you for the analysis and further discussion! I have done some rudimentary printk debugging in QEMU and it looks like these are produce the same value: __stop___trace_bprintk_fmt &__stop___trace_bprintk_fmt &__start___trace_bprintk_fmt[0] as well as __stop___trace_bprintk_fmt != __start___trace_bprintk_fmt &__stop___trace_bprintk_fmt != &__start___trace_bprintk_fmt &__stop___trace_bprintk_fmt[0] != &__start___trace_bprintk_fmt[0] I'll use the second one once I confirm this is true in all callspots with both Clang and GCC, since it looks cleaner. Let me know if there are any objections to that. Cheers, Nathan