Re: [net-next PATCH v2 2/2] page_pool: remove hold/release count from tracepoints

[Jesper Dangaard Brouer <brouer@redhat.com>]

On Thu, 14 Nov 2019 08:37:15 -0800
Jonathan Lemon <jonathan.lemon@gmail.com> wrote:

> When the last page is released from the page pool, it is possible
> that the delayed removal thread sees inflight == 0, and frees the
> pool.  While the freed pointer is only copied by the tracepoint
> and not dereferenced, it really isn't correct.  Avoid this case by
> reporting the page release before releasing the page.

I don't like this patch!

I'm actually using these counters, in my current version of my bpftrace
leak detector for page_pool:

https://github.com/xdp-project/xdp-project/blob/master/areas/mem/bpftrace/page_pool_track_leaks01.bt



> This also removes a second atomic operation from the release path.
> 
> Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
> ---
>  include/trace/events/page_pool.h | 24 ++++++++++--------------
>  net/core/page_pool.c             |  8 +++++---
>  2 files changed, 15 insertions(+), 17 deletions(-)
[...]

> @@ -222,9 +222,11 @@ static void __page_pool_clean_page(struct page_pool *pool,
>  			     DMA_ATTR_SKIP_CPU_SYNC);
>  	page->dma_addr = 0;
>  skip_dma_unmap:
> +	trace_page_pool_page_release(pool, page);
> +	/* This may be the last page returned, releasing the pool, so
> +	 * it is not safe to reference pool afterwards.
> +	 */
>  	atomic_inc(&pool->pages_state_release_cnt);
> -	trace_page_pool_state_release(pool, page,
> -			      atomic_read(&pool->pages_state_release_cnt));
>  }

I will prefer that you do an atomic_inc_return, and send the cnt to the
existing tracepoint.  I'm not dereferencing the pool in my tracepoint
use-case, and as Alexei wrote, this would still be 'safe' (as in not
crashing) for a tracepoint if someone do.

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer