From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF02CC43334 for ; Tue, 19 Jul 2022 15:43:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1CA946B0074; Tue, 19 Jul 2022 11:43:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 153CD6B0075; Tue, 19 Jul 2022 11:43:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F36246B0078; Tue, 19 Jul 2022 11:43:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id DFF646B0074 for ; Tue, 19 Jul 2022 11:43:25 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B056AA0210 for ; Tue, 19 Jul 2022 15:43:25 +0000 (UTC) X-FDA: 79704268770.01.F1787F6 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf16.hostedemail.com (Postfix) with ESMTP id F0932180008 for ; Tue, 19 Jul 2022 15:43:24 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id BB5AD348B7; Tue, 19 Jul 2022 15:43:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1658245403; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NG6X28gAOlRl2/6jzvTSSGutMpFbGaBg493qNWflstQ=; b=hZbGdx+QM0rjB17dXa/+05R1GiMe06VCXmh4quE4k+/ZvVqrhY7qpi8ZJM/B3fOBoo7sAw JlpCdwR2V0aYiMNKjJ4fgZ3FH0pZNzgFT394CZpC8PLILC4OrfXMOncK5tDd223iwg0hBh YNIK8je0xS3HVbjut/EPwqfHgXGuuMI= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 339D32C141; Tue, 19 Jul 2022 15:43:20 +0000 (UTC) Date: Tue, 19 Jul 2022 17:43:19 +0200 From: Michal Hocko To: Charan Teja Kalla Cc: akpm@linux-foundation.org, pasha.tatashin@soleen.com, sjpark@amazon.de, sieberf@amazon.com, shakeelb@google.com, dhowells@redhat.com, willy@infradead.org, vbabka@suse.cz, david@redhat.com, minchan@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, "iamjoonsoo.kim@lge.com" , Pavan Kondeti Subject: Re: [PATCH] mm: fix use-after free of page_ext after race with memory-offline Message-ID: References: <1657810063-28938-1-git-send-email-quic_charante@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=hZbGdx+Q; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658245405; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NG6X28gAOlRl2/6jzvTSSGutMpFbGaBg493qNWflstQ=; b=lDlKYUXSCKJiNbbaw8pPp6LQqZA98seDnolU4K3wHtR3Wc7fgcqN9WJu0YYY62GEhzUD2T Mup7ePvlGfb0jQ3zdnEiUhmpoW08vqWJgxmxnLT6/Js/jZAKVD+sR+4ubVCtyDuGz+Z8bB JYdpuHaEKXycKi/DQ7n0dILGoD/m/DI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658245405; a=rsa-sha256; cv=none; b=TOPBHjJLzYar8KL9EQheY4PWVqox4kR2rf6sOYjCFSdk8YAPBP8yPql7MZq8D93VTf8YfT QqbHlwCCZ0NAyahvSjvHvi2y7BAfMJmwHbM+nYL3e71z8eTByI5/8xkKy8KGMQE1Vbp4yQ hFJsG8YF+LmXuWYVbrds0If7pz78iXE= X-Stat-Signature: wjdh5hzcppp9tpkbefxdz1zaua37yfpn X-Rspamd-Queue-Id: F0932180008 X-Rspam-User: Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=hZbGdx+Q; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam11 X-HE-Tag: 1658245404-955729 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue 19-07-22 20:42:42, Charan Teja Kalla wrote: > Thanks Michal!! > > On 7/18/2022 8:24 PM, Michal Hocko wrote: [...] > >>>> diff --git a/mm/page_ext.c b/mm/page_ext.c > >>>> index 3dc715d..5ccd3ee 100644 > >>>> --- a/mm/page_ext.c > >>>> +++ b/mm/page_ext.c > >>>> @@ -299,8 +299,9 @@ static void __free_page_ext(unsigned long pfn) > >>>> if (!ms || !ms->page_ext) > >>>> return; > >>>> base = get_entry(ms->page_ext, pfn); > >>>> - free_page_ext(base); > >>>> ms->page_ext = NULL; > >>>> + synchronize_rcu(); > >>>> + free_page_ext(base); > >>>> } > >>> So you are imposing the RCU grace period for each page_ext! This can get > >>> really expensive. Have you tried to measure the effect? > > I was wrong here! This is for each memory section which is not as > > terrible as every single page_ext. This can be still quite a lot memory > > sections in a single memory block (e.g. on ppc memory sections are > > ridiculously small). > > > > On the ARM64, I see that the minimum a section size will go is 128MB. I > think 16MB is the section size on ppc. Any inputs on how frequently > offline/online operation is being done on this ppc arch? I have seen several reports where 16MB sections were used on PPC LPARs with a non trivial size. My usual answer to that is tha this is mostly a self inflicted injury but I am told that for some reasons I cannot udnerstand this is not easy to change. So reasonable or not this is not all that uncommon in PPC land. We definitely shouldn't optimize for those setups but we shouldn't make them suffer even more as well. Besides that it seems that a single rcu_synchronize per offline operation should be doable. -- Michal Hocko SUSE Labs