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 97966C4828D for ; Mon, 5 Feb 2024 09:31:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2532F6B0074; Mon, 5 Feb 2024 04:31:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1DCFC6B0078; Mon, 5 Feb 2024 04:31:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 055EF6B007B; Mon, 5 Feb 2024 04:31:33 -0500 (EST) 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 E4B876B0074 for ; Mon, 5 Feb 2024 04:31:33 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B577FA18CD for ; Mon, 5 Feb 2024 09:31:33 +0000 (UTC) X-FDA: 81757232466.08.6B1655B Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf08.hostedemail.com (Postfix) with ESMTP id 80674160017 for ; Mon, 5 Feb 2024 09:31:31 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=A+FdiCLx; dkim=pass header.d=suse.com header.s=susede1 header.b=A+FdiCLx; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf08.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 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=1707125491; 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=VHKojVI/8ySxfySQRj9+91SsbIPCFSWZG8hNQz2bKC0=; b=eB3gKO5LPcWeqvypSYY8Vn+F8WS+HvoKhBJWOa5RCmhro2g0iklTKQnxKdYuj2ryw81yv7 uiYKBnY8xs8zzDD1G6NydbCAGovCVS7PxNOgAkrdfYXJI3qtL40B5bkrKgOuFm7dGWfWL3 6/6/rwVrmtkvDRUL1VBHjpARtrYrbnY= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=A+FdiCLx; dkim=pass header.d=suse.com header.s=susede1 header.b=A+FdiCLx; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf08.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707125491; a=rsa-sha256; cv=none; b=e7WJxHZoWh38QvzcW7eLzEp484RSfl6CDBJQfVO+1C7aPJeLiIx75N1vhAI3tnG3IBp+MV Z5n/AUKSc5++IZ7z0UfQPs6EnCTj7EAQmH6lQnQiQWSHiqRuDIx7FXiwClrabnvaPm1tVL z1HRZlPODNrbG3qQ36dcTldAJ/XY7fA= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 8DCAE22105; Mon, 5 Feb 2024 09:31:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1707125489; 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=VHKojVI/8ySxfySQRj9+91SsbIPCFSWZG8hNQz2bKC0=; b=A+FdiCLxQ2gODITcsJtDVVKXcIr3wUKZ04FqK+ifSv1l7tHErcPUwO34233AP4xq58mKRw 3GbgrTC4uxYzFDoTnI0vYfdDuwPjhbOUbMKgxIYJ5xOEfm4Aij8+sbkfG471b7N1zExYC6 Q7UtS8ZFnOYQZLYzExEQ8sS7ysUCNQg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1707125489; 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=VHKojVI/8ySxfySQRj9+91SsbIPCFSWZG8hNQz2bKC0=; b=A+FdiCLxQ2gODITcsJtDVVKXcIr3wUKZ04FqK+ifSv1l7tHErcPUwO34233AP4xq58mKRw 3GbgrTC4uxYzFDoTnI0vYfdDuwPjhbOUbMKgxIYJ5xOEfm4Aij8+sbkfG471b7N1zExYC6 Q7UtS8ZFnOYQZLYzExEQ8sS7ysUCNQg= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 60C98136F5; Mon, 5 Feb 2024 09:31:29 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id Ky2fFPGqwGWiHwAAD6G6ig (envelope-from ); Mon, 05 Feb 2024 09:31:29 +0000 Date: Mon, 5 Feb 2024 10:31:28 +0100 From: Michal Hocko To: Baolin Wang Cc: akpm@linux-foundation.org, muchun.song@linux.dev, osalvador@suse.de, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: hugetlb: fix hugetlb allocation failure when handling freed or in-use hugetlb Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: 5xh6ju7surc1x76q3r5qyetkcubcphqg X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 80674160017 X-HE-Tag: 1707125491-672538 X-HE-Meta: U2FsdGVkX1/yKGH0JSa0brRK5vlWl+OHw4Xvwv79VXG/Xs3r7qO4xYf/Wplt7KuMxLP0o4/l73rsLLjMoOvzTb9Umvv2dne9SoRbdt+R6KxkEHamxxNCziBMPw/h7YJwyGeBuWcoIrys8sEsuyetRcZZ0kjpnY1oJxjsR3XWCmP1aWRbhIKxeF2BsNbyv/LOGtGhCLZwtCd5qIuaIh0QtMlj/IAe6+IjjmDNV6fVboGHTKSUKPu+xWpVH9XsGBWoSnjfbWgQ9rQJ/52qaMeo+OWREAYuWvcfTDI9wtJa2k6TMKSe5K2XFvKbi4kbg0C9IE/QfyimvioRCZ4IAaUKATNWyBSP9H54wiSn6bFzjuAfLnSgZJAgSjN2XTSRgJv7MFNjiZDwnpeEfWwa5pMu8IXl3OCJGx1sZFZ5jBShs4R4QW55Gk7cgHsLUWJVDeKlxP9GLGr4KNTJRZgxprjJ2mNN+j41nuIec64OgVeJRAd9GYh4peLBkUgdtZq5brXseahTayvnFMDT8aXg6Q2JVZQpGdNhxlLxiwvHT++4Sp0f3UnhK/cDzkbjhqaSwkHjmkfLp8CqdkVQYJZ6MjVv0afHofSLiIaYPY6iQGd6y87hzIPHWxJRW/LBDItUpAVS4ZenP3mlI7fQEidGimLo5ioUNi7jhLFPkp9qRcAM+QaDctCm4CRD4wz9USbWxD7S5GbtzCj/gpRnSnYfUTmuE5g0EuG/vhl3z76vm8+iRWfw7b7xQ6X3kTiKLlWq6BT6CpyOSOG1NKAOd2yKwD2QXlHk6i11A3kxvneJjN3K0AZsYqStybfjDP1QYJ9YvVNGN6d+GdoQ88JUF9N/iEJitzRDsywML/Ho2YNJe3NrK0z4TiTSeDuOtt7FtZEKN7YXpmcMYNIpnTjmGVabQc+kYlrMJE5UuiqwOiKv3G/hadcFTNd7LjLPtF+dB/AQsX8rZ6TKkrPTiGqT7mClx8l gw5Qrtlh r+7PBzKz7XddhrQaV2pAHFKxm4v8WaSyBZYaVnup5dT/VdneAy63LNrpnhylLR3QQf54MhPm3QbJ3K6CzitboF5rBJTOyIZF7vkZNfEyt4nqin/tFOXuZ2QkJDoV8sUDbfyUjf0BmW17DipFZqXKwKZ5mDPnHgBA+YU7HVGcNChvHf3SJGVGjR15GYmGGgYkQylD45U5aBTuegV7bj8UTIZ2cb12GauVt1sU4D3F7yaMf+HY= 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: List-Subscribe: List-Unsubscribe: On Mon 05-02-24 11:54:17, Baolin Wang wrote: > When handling the freed hugetlb or in-use hugetlb, we should ignore the > failure of alloc_buddy_hugetlb_folio() to dissolve the old hugetlb successfully, > since we did not use the new allocated hugetlb in this 2 cases. > > Signed-off-by: Baolin Wang > --- > mm/hugetlb.c | 18 ++++++++++++------ > 1 file changed, 12 insertions(+), 6 deletions(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index 9d996fe4ecd9..212ab331d355 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -3042,9 +3042,8 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h, > * under the lock. > */ > new_folio = alloc_buddy_hugetlb_folio(h, gfp_mask, nid, NULL, NULL); > - if (!new_folio) > - return -ENOMEM; > - __prep_new_hugetlb_folio(h, new_folio); > + if (new_folio) > + __prep_new_hugetlb_folio(h, new_folio); Is there any reason why you haven't moved the allocation to the only branch that actually needs it? I know that we hold hugetlb lock but you could have easily dropped the lock, allocate a page and then goto retry. This would actually save an allocation. Something like this: diff --git a/mm/hugetlb.c b/mm/hugetlb.c index ed1581b670d4..db5f72b94422 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -3029,21 +3029,9 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h, { gfp_t gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE; int nid = folio_nid(old_folio); - struct folio *new_folio; + struct folio *new_folio = NULL; int ret = 0; - /* - * Before dissolving the folio, we need to allocate a new one for the - * pool to remain stable. Here, we allocate the folio and 'prep' it - * by doing everything but actually updating counters and adding to - * the pool. This simplifies and let us do most of the processing - * under the lock. - */ - new_folio = alloc_buddy_hugetlb_folio(h, gfp_mask, nid, NULL, NULL); - if (!new_folio) - return -ENOMEM; - __prep_new_hugetlb_folio(h, new_folio); - retry: spin_lock_irq(&hugetlb_lock); if (!folio_test_hugetlb(old_folio)) { @@ -3073,6 +3061,15 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h, cond_resched(); goto retry; } else { + + if (!new_folio) { + spin_unlock_irq(&hugetlb_lock); + new_folio = alloc_buddy_hugetlb_folio(h, gfp_mask, nid, NULL, NULL); + if (!new_folio) + return -ENOMEM; + __prep_new_hugetlb_folio(h, new_folio); + goto retry; + } /* * Ok, old_folio is still a genuine free hugepage. Remove it from * the freelist and decrease the counters. These will be @@ -3100,9 +3097,11 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h, free_new: spin_unlock_irq(&hugetlb_lock); - /* Folio has a zero ref count, but needs a ref to be freed */ - folio_ref_unfreeze(new_folio, 1); - update_and_free_hugetlb_folio(h, new_folio, false); + if (new_folio) { + /* Folio has a zero ref count, but needs a ref to be freed */ + folio_ref_unfreeze(new_folio, 1); + update_and_free_hugetlb_folio(h, new_folio, false); + } return ret; } -- Michal Hocko SUSE Labs