netdev - Re: [RFC PATCH 1/1] page_pool: do not release pool until inflight == 0.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 11 Nov 2019 10:21:04 +0100
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Jonathan Lemon <jonathan.lemon@...il.com>
Cc:     <netdev@...r.kernel.org>, <ilias.apalodimas@...aro.org>,
        <kernel-team@...com>, brouer@...hat.com
Subject: Re: [RFC PATCH 1/1] page_pool: do not release pool until inflight
 == 0.

On Sun, 10 Nov 2019 22:20:38 -0800
Jonathan Lemon <jonathan.lemon@...il.com> wrote:

> diff --git a/net/core/xdp.c b/net/core/xdp.c
> index 20781ad5f9c3..e334fad0a6b8 100644
> --- a/net/core/xdp.c
> +++ b/net/core/xdp.c
> @@ -70,25 +70,47 @@ static void __xdp_mem_allocator_rcu_free(struct rcu_head *rcu)
>  
>  	xa = container_of(rcu, struct xdp_mem_allocator, rcu);
>  
> -	/* Allocator have indicated safe to remove before this is called */
> -	if (xa->mem.type == MEM_TYPE_PAGE_POOL)
> -		page_pool_free(xa->page_pool);
> -
>  	/* Allow this ID to be reused */
>  	ida_simple_remove(&mem_id_pool, xa->mem.id);
>  
> -	/* Poison memory */
> -	xa->mem.id = 0xFFFF;
> -	xa->mem.type = 0xF0F0;
> -	xa->allocator = (void *)0xDEAD9001;
> -
>  	kfree(xa);
>  }

Can you PLEASE leave the memory poisonings that I have added alone.
Removing these are irrelevant for current patch. You clearly don't like
this approach, but I've also clearly told that I disagree.  I'm the
maintainer of this code and I prefer letting them stay. I'm the one
that signed up for dealing with hard to find bugs in the code.

I'll try to explain again, hopefully one last time.  You argue that the
memory subsystem already have use-after-free detection e.g via
kmemleak.  I argue that these facilities change the timing so much,
that race condition will not be provoked when enabled.  This is not
theoretical, I've seen bugzilla cases consume a huge amount of support
and engineering resources, trying to track down bugs that would
disappear once the debug facility is enabled.

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