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;
Date:   Tue, 7 Aug 2018 11:05:44 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Fubo Chen <fubo.chen@gmail.com>
Cc:     jpoimboe@redhat.com, Ingo Molnar <mingo@kernel.org>,
        bhole_prashant_q7@lab.ntt.co.jp,
        Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] perf/x86/intel: Fix unwind errors from PEBS entries
 (mk-II)
Message-ID: <20180807090544.GX2494@hirez.programming.kicks-ass.net>
References: <20180719153347.buoe6pavpqc75zbb@treble>
 <20180719174311.GK2494@hirez.programming.kicks-ass.net>
 <20180719211954.GZ2512@hirez.programming.kicks-ass.net>
 <CAJAFBLDtRUwYhMaOrgHer4eTvjWL2jC-fy0GGv+Pjd8q3wgywA@mail.gmail.com>
 <20180806154235.GO2494@hirez.programming.kicks-ass.net>
 <CAJAFBLCt574QmeP5N9D-d+Sc67BWQ5E2C=LhqFVvUpchC4O3PQ@mail.gmail.com>
 <20180806180423.GC2476@hirez.programming.kicks-ass.net>
 <CAJAFBLA2WigOMxuWXxZvHVwuGtvYr3_b4gpNbdGzry-=AVxjqA@mail.gmail.com>
 <20180806223008.GW2494@hirez.programming.kicks-ass.net>
 <CAJAFBLDzX78w=uaTdBQ_obb9hBMLGXG1Ec0hb199HEXxXQBPjQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJAFBLDzX78w=uaTdBQ_obb9hBMLGXG1Ec0hb199HEXxXQBPjQ@mail.gmail.com>
User-Agent: Mutt/1.10.0 (2018-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Aug 06, 2018 at 04:04:40PM -0700, Fubo Chen wrote:
> On Mon, Aug 6, 2018 at 3:30 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Mon, Aug 06, 2018 at 02:28:18PM -0700, Fubo Chen wrote:
> > > Do you think the patch below is sufficient to suppress the sparse warning?
> >
> > Why would I want to make the code ugly to supress it?
> 
> There are many kernel developers who use sparse to verify the
> correctness of endianness annotations (__be32, __le32, ...). When
> compiling kernel code with sparse every warning that is reported by
> sparse should be analyzed. Most kernel developers consider it annoying
> having to deal with false positive warnings. So I think that is useful
> to suppress false positive sparse warnings if it is possible to
> suppress false positives with a reasonable effort.

Last time I used sparse there were a metric ton of warnings. I really
can't be bothered about one more. Maybe fix sparse if you're bothered?