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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 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 323F0C34056 for ; Wed, 19 Feb 2020 19:43:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C9B13208E4 for ; Wed, 19 Feb 2020 19:43:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C9B13208E4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7968C6B0006; Wed, 19 Feb 2020 14:43:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 745D86B0007; Wed, 19 Feb 2020 14:43:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 682896B0008; Wed, 19 Feb 2020 14:43:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0219.hostedemail.com [216.40.44.219]) by kanga.kvack.org (Postfix) with ESMTP id 4D9806B0006 for ; Wed, 19 Feb 2020 14:43:38 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id F004640E1 for ; Wed, 19 Feb 2020 19:43:37 +0000 (UTC) X-FDA: 76507901274.28.snail00_3cc2ee54a0c58 X-HE-Tag: snail00_3cc2ee54a0c58 X-Filterd-Recvd-Size: 3141 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Wed, 19 Feb 2020 19:43:37 +0000 (UTC) Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 42C84207FD; Wed, 19 Feb 2020 19:43:35 +0000 (UTC) Date: Wed, 19 Feb 2020 14:43:33 -0500 From: Steven Rostedt To: Nathan Chancellor Cc: Nick Desaulniers , Jason Gunthorpe , 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: <20200219144333.1ce3f9ea@gandalf.local.home> In-Reply-To: <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> <20200219192249.GA8840@ubuntu-m2-xlarge-x86> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 19 Feb 2020 12:22:49 -0700 Nathan Chancellor wrote: > 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. Myself and I'm sure others would be fine with this approach as it is still readable. I was just against the encapsulating the logic in a strange macro that killed readability. I haven't looked at the resulting assembly from these, and will currently take your word for it ;-) Of course, I will thoroughly test any patches to this code to make sure it does not hurt functionality. -- Steve