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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D95CEC433DB for ; Thu, 7 Jan 2021 14:11:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 56E5422DBF for ; Thu, 7 Jan 2021 14:11:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56E5422DBF Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 36DB56B02C1; Thu, 7 Jan 2021 09:11:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 31E816B02C6; Thu, 7 Jan 2021 09:11:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20CB96B02CA; Thu, 7 Jan 2021 09:11:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id 067446B02C1 for ; Thu, 7 Jan 2021 09:11:36 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A907D364E for ; Thu, 7 Jan 2021 14:11:35 +0000 (UTC) X-FDA: 77679166950.21.place79_590cf94274ea Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id 71210180442C7 for ; Thu, 7 Jan 2021 14:11:35 +0000 (UTC) X-HE-Tag: place79_590cf94274ea X-Filterd-Recvd-Size: 3409 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Jan 2021 14:11:34 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1610028693; 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=d/0aJd6L6cFlMGhErbrEFew79EQmA27uvTCPjDXMcns=; b=m02pAfMHvIF+TcFwI29qCrYeH501CPFnrCwYHhh8IXlpgSNW9evNAMK+HPf/Cma8zM2oUW A5M3K4cRMKJapbwN8zIli+GQkaWE33QyuyMJMUukAVHDob0Z7bAaqU+ZtyLUXoOLknzq2Y 5hLcVjGD0Xrz3ExoPvLHNYlI00g5FAo= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id A425AB748; Thu, 7 Jan 2021 14:11:33 +0000 (UTC) Date: Thu, 7 Jan 2021 15:11:30 +0100 From: Michal Hocko To: Muchun Song Cc: Mike Kravetz , Andrew Morton , Naoya Horiguchi , Andi Kleen , Linux Memory Management List , LKML Subject: Re: [External] Re: [PATCH v2 3/6] mm: hugetlb: fix a race between freeing and dissolving the page Message-ID: <20210107141130.GL13207@dhcp22.suse.cz> References: <20210106084739.63318-1-songmuchun@bytedance.com> <20210106084739.63318-4-songmuchun@bytedance.com> <20210106165632.GT13207@dhcp22.suse.cz> <20210107084146.GD13207@dhcp22.suse.cz> <20210107111827.GG13207@dhcp22.suse.cz> <20210107123854.GJ13207@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Thu 07-01-21 20:59:33, Muchun Song wrote: > On Thu, Jan 7, 2021 at 8:38 PM Michal Hocko wrote: [...] > > Right. Can we simply back off in the dissolving path when ref count is > > 0 && PageHuge() if list_empty(page->lru)? Is there any other scenario > > when the all above is true and the page is not being freed? > > The list_empty(&page->lru) may always return false. > The page before freeing is on the active list > (hstate->hugepage_activelist).Then it is on the free list > after freeing. So list_empty(&page->lru) is always false. The point I was trying to make is that the page has to be enqueued when it is dissolved and freed. If the page is not enqueued then something racing. But then I have realized that this is not a great check to detect the race because pages are going to be released to buddy allocator and that will reuse page->lru again. So scratch that and sorry for the detour. But that made me think some more and one way to reliably detect the race should be PageHuge() check in the freeing path. This is what dissolve path does already. PageHuge becomes false during update_and_free_page() while holding the hugetlb_lock. So can we use that? -- Michal Hocko SUSE Labs