Re: [RFC PATCH] perf/core: Prevent dereferencing NULL pointer

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Feb 10, 2025 at 04:07:48PM +0800, I Hsin Cheng wrote:
> 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?

Right, the vma / mapping has a refcount on the event, the event has a
refcount on the buffer, and event->mmap_count is incremented, which
makes sure event->rb isn't changd.

So yes, at the time of perf_mmap_close() it *should* be impossible for
ring_buffer_get() to return NULL.