[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z6mz1A804NXZpFm-@vaxr-BM6660-BM6360>
Date: Mon, 10 Feb 2025 16:07:48 +0800
From: I Hsin Cheng <richard120310@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: mark.rutland@....com, mingo@...hat.com, acme@...nel.org,
namhyung@...nel.org, alexander.shishkin@...ux.intel.com,
jolsa@...nel.org, irogers@...gle.com, adrian.hunter@...el.com,
kan.liang@...ux.intel.com, linux-perf-users@...r.kernel.org,
linux-kernel@...r.kernel.org, jserv@...s.ncku.edu.tw,
shuah@...nel.org
Subject: Re: [RFC PATCH] perf/core: Prevent dereferencing NULL pointer
On Thu, Feb 06, 2025 at 09:05:20AM +0100, Peter Zijlstra wrote:
> On Thu, Feb 06, 2025 at 03:06:08AM +0800, I Hsin Cheng wrote:
> > According to coverity scan check, there's possible cases where
> > "ring_buffer_get()" returns a NULL in "perf_mmap_close".
>
> That makes no sense. Having a mmap should pin the buffer.
>
> > Use a "BUG_ON()" to check for NULL pointer existence, panic if it does
> > exist, otherwise it's safe to dereference "rb" and access its members.
>
> How the hell is a BUG_ON() any better than a NULL deref?
>
Hi Peter,
Thanks for the review ! I get it so I think this issue reported by
coverity scan should be marked as false positive or disgard.
> That makes no sense. Having a mmap should pin the buffer.
I see, so if I understand correctly, the "event" in perf_mmap_close()
is guaranteed to have available buffer and the buffer's refcount is
zero, so returning a NULL will never happen right?
Regards,
I Hsin
Powered by blists - more mailing lists