Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <f670c6ee-1c20-570f-68f9-42a3e1e85557@quicinc.com>
Date:   Mon, 1 Aug 2022 17:20:19 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: [PATCH V2] mm: fix use-after free of page_ext after race with
 memory-offline
Content-Language: en-US
To:     David Hildenbrand <david@redhat.com>, <akpm@linux-foundation.org>,
        <quic_pkondeti@quicinc.com>, <pasha.tatashin@soleen.com>,
        <sjpark@amazon.de>, <sieberf@amazon.com>, <shakeelb@google.com>,
        <dhowells@redhat.com>, <willy@infradead.org>,
        <liuting.0x7c00@bytedance.com>, <minchan@kernel.org>,
        Michal Hocko <mhocko@suse.com>
CC:     <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
References: <1658931303-17024-1-git-send-email-quic_charante@quicinc.com>
 <6168cf49-bf75-2ebb-ab55-30de473835e3@redhat.com>
 <a26ce299-aed1-b8ad-711e-a49e82bdd180@quicinc.com>
 <3fc8a61b-ad70-8092-9197-4920e0897593@redhat.com>
From:   Charan Teja Kalla <quic_charante@quicinc.com>
In-Reply-To: <3fc8a61b-ad70-8092-9197-4920e0897593@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk

Thanks David!!

On 8/1/2022 2:00 PM, David Hildenbrand wrote:
>> Having said that, I am open to go for call_rcu() and infact it will be a
>> much simple change where I can do the freeing of page_ext in the
>> __free_page_ext() itself which is called for every section there by
>> avoid the extra tracking flag PAGE_EXT_INVALID.
>>       ...........
>>         WRITE_ONCE(ms->page_ext, NULL);
>> 	call_rcu(rcu_head, fun); // Free in fun()
>>        .............
>>
>> Or your opinion is to use call_rcu () only once in place of
>> synchronize_rcu() after invalidating all the page_ext's of memory block?
> 
> Yeah, that would be an option. And if you fail to allocate a temporary
> buffer to hold the data-to-free (structure containing rcu_head), the
> slower fallback path would be synchronize_rcu().
> 

I will add this as a note in the code that in future If some
optimizations needs to be done in this path, this option can be
considered.  Hope this will be fine for now?

> But again, I'm also not sure if we have to optimize here right now.

Thanks,
Charan