From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <netdev-owner@vger.kernel.org>
Received: from mail-pl0-f65.google.com ([209.85.160.65]:44912 "EHLO
        mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751395AbeCWOzm (ORCPT
        <rfc822;netdev@vger.kernel.org>); Fri, 23 Mar 2018 10:55:42 -0400
Received: by mail-pl0-f65.google.com with SMTP id 9-v6so7561338ple.11
        for <netdev@vger.kernel.org>; Fri, 23 Mar 2018 07:55:42 -0700 (PDT)
Subject: Re: [bpf-next V5 PATCH 11/15] page_pool: refurbish version of
 page_pool code
To: Jesper Dangaard Brouer <brouer@redhat.com>,
        Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org,
        =?UTF-8?B?QmrDtnJuVMO2cGVs?= <bjorn.topel@intel.com>,
        magnus.karlsson@intel.com, eugenia@mellanox.com,
        Jason Wang <jasowang@redhat.com>,
        John Fastabend <john.fastabend@gmail.com>,
        Eran Ben Elisha <eranbe@mellanox.com>,
        Saeed Mahameed <saeedm@mellanox.com>, galp@mellanox.com,
        Daniel Borkmann <borkmann@iogearbox.net>,
        Alexei Starovoitov <alexei.starovoitov@gmail.com>,
        Tariq Toukan <tariqt@mellanox.com>
References: <152180742196.20167.5168801400337773178.stgit@firesoul>
 <152180753479.20167.856688163861554435.stgit@firesoul>
 <b8463e12-d1eb-d862-c5f4-09fc0ac33382@gmail.com>
 <20180323151522.2d3dde07@redhat.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Message-ID: <796ac33b-26cc-107b-debe-17b5cfceab97@gmail.com>
Date: Fri, 23 Mar 2018 07:55:37 -0700
MIME-Version: 1.0
In-Reply-To: <20180323151522.2d3dde07@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>



On 03/23/2018 07:15 AM, Jesper Dangaard Brouer wrote:
> On Fri, 23 Mar 2018 06:29:55 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 
>> On 03/23/2018 05:18 AM, Jesper Dangaard Brouer wrote:
>>
>>> +
>>> +void page_pool_destroy_rcu(struct page_pool *pool)
>>> +{
>>> +	call_rcu(&pool->rcu, __page_pool_destroy_rcu);
>>> +}
>>> +EXPORT_SYMBOL(page_pool_destroy_rcu);
>>>   
>>
>>
>> Why do we need to respect one rcu grace period before destroying a page pool ?
> 
> Due to previous allocator ID patch, which can have a pointer reference
> to a page_pool, and the allocator ID lookup uses RCU.
> 

I am not convinced.  How comes a patch that is _before_ this one can have any impact ?

Normally, we put first infrastructure, then something using it.

rcu grace period before freeing huge quantitites of pages is problematic and could
be used by syzbot to OOM the host.