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 7D935E8FDC1 for ; Wed, 4 Oct 2023 00:20:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B8C686B0255; Tue, 3 Oct 2023 20:20:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B15126B0256; Tue, 3 Oct 2023 20:20:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B5336B0258; Tue, 3 Oct 2023 20:20:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 872A96B0255 for ; Tue, 3 Oct 2023 20:20:29 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4BFAD14035F for ; Wed, 4 Oct 2023 00:20:29 +0000 (UTC) X-FDA: 81305872578.15.283D9AB Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf20.hostedemail.com (Postfix) with ESMTP id B626C1C0017 for ; Wed, 4 Oct 2023 00:20:26 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; dmarc=none; spf=none (imf20.hostedemail.com: domain of riel@shelob.surriel.com has no SPF policy when checking 96.67.55.147) smtp.mailfrom=riel@shelob.surriel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696378826; h=from:from:sender: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IBuLPWu5odhks9OB6hlgMVKlYtuUQmfbn0oa8ku+Wkk=; b=LFokvBgkL9TNXLI+zwbRubDoCyu2jkuX4/pDRzEEhEfG8kUqyLQsoUrqa/Wlu1fGPVHsHn rjh1PeP1w39/A//67rAv9pV9g33OSvVjGWn/euaaqrNCX4Fnw/8ndIBytUpN1jbUvdixSf iWwsQ10lNyU2tC0hd3BEKjNcUk6AO/c= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; dmarc=none; spf=none (imf20.hostedemail.com: domain of riel@shelob.surriel.com has no SPF policy when checking 96.67.55.147) smtp.mailfrom=riel@shelob.surriel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696378826; a=rsa-sha256; cv=none; b=p8tMdCBseHr/1ndEmPlksGopK0adzazhHkdD4CK6UE9KQwYln+sIRpg8LN11JcQI7k54Lk qEl4WnOt5nljdLrpr6u3Docs/SKWC39aiwX3CVRFQs9YY+83CJIYElJAKJOXB7k+luDZLe otk0hecI6a2k/Rlupw8WsQC4vQXfxFE= Received: from imladris.home.surriel.com ([10.0.13.28] helo=imladris.surriel.com) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qnpcQ-0003RO-2X; Tue, 03 Oct 2023 20:20:02 -0400 Message-ID: Subject: Re: [PATCH 2/3] hugetlbfs: close race between MADV_DONTNEED and page fault From: Rik van Riel To: Mike Kravetz Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com, linux-mm@kvack.org, akpm@linux-foundation.org, muchun.song@linux.dev, leit@meta.com, willy@infradead.org Date: Tue, 03 Oct 2023 20:20:02 -0400 In-Reply-To: <20231003201916.GD314430@monkey> References: <20231001005659.2185316-1-riel@surriel.com> <20231001005659.2185316-3-riel@surriel.com> <20231002043958.GB11194@monkey> <8d19b6d092b7b5d9b1d0829e0d99c9915db3ed61.camel@surriel.com> <20231003201916.GD314430@monkey> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) MIME-Version: 1.0 X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: B626C1C0017 X-Stat-Signature: hsg8ddqjgkfrzxwjuokcjww138nqwscu X-Rspam-User: X-HE-Tag: 1696378826-801402 X-HE-Meta: U2FsdGVkX1+SgyFKx8H6vfJiCljyYcIxn4Fq+s2LKTGOE5IpmZTtNLnTI7iabszPIih3egHcF/S0UIxrW2UhjQpKynW8+29nNC+rkRdlrrpQ0ZARle86oVWApqt4BMB+plgmZEQt4ATPODVdmTpmOzgbsMKA/v+TvhntTJp/gSxcpOPIBibPe/74N1FJer2JfuaD/VEaHsSkxCEaI+oxh8UgokTTaF6ggYCiCIbZX2K8ZNoenpistzjeBY7JNycE+oHLzSUuAk5Bq7TSWPQ1UsQxIRpj198WhjTvLUYnsD7eg4Dvrs8dFFHrTMG1DQVkQLlTXJEMiKjln/VS4ZT9Pd5qL/3NdOzRHkSmlfc3FByswrH7CSnTCy0V5YpQdo3GQkXcYq1MvCgNRfHFSDzwo7bpyLUDtqNQrEXWpM0BnKwQsXRR3iOTmbcCAvFNEV1Zrv5BlP7sdIgXzZ/b9LWIiMhG+kaIQDpnuLMZscBUhdlZLyvwfpOdhKx8icmCCSJPZkvZIOuE7ecsT21rbX8Nz2t2NJaEL2dl3Wqg2u4NGFGYo1Q/1MJY1lARIC7rKQ/dzMnUFRFAbfC+wIlZo9D/syHm+IAEhyDExpEGeW6sj3EmrNxa+oXMHAUEt0DwQRIhZfCjqogQoOvaex28Cv4r2YsfL7scWhwD8BTPVJ0keyCeeXXdt56ZaiPecNPg7WBr4YRWHc83xnkHAlAcNjBs0eY85zCwR0UswvpT62S2D6nNJFBj3NoRf7v9aYvWpvgKX0+BNY3hq0QC/gjK4ykVHCeOxuhSJgcYzzMCbWlpq9FMyBio0XQolnZvSBcpQJDpNjWZhO1tzdT4nFRok8kK2P9bByth2yA8qWx0qachcLIhNtseocobqCS39NNFBQwzIoVVnMHsgKKbl1xQLI4vRHsPi7+K+7aqKExL38DjoOVkw0bFxadDcqMpT/O4dyfAkd0Q1zP9+QySSuozwSi +uJXzyh6 0CEQ+wZhauoKQFvcWZ0fXN8E2bAt6AjlEFS98gpCJWfWy9FBp8fl8weqLbBUMBAByVysIsMmYH91Vh7pODIEKifcGRX4mkknPrTkVxa44GFTy4k5A8fvOeXEck+bd5B/vf3WcoO2swoJ4wiXq7VsVhj6jXIlDc+d7fYj8sm7PxeLst40sSNl1LKWwQmDH6cN3W5g024ZreT9nBUYLNANB3UBdyw1O55TD4dG6iKub3/cALL/RrERf2Fy+wBaAmvQPC7lxY2BZy/B0wkQHk/TcJU75si1xOW649M+9Aj2BckJhfZzP8HMIQqVn+m5GjLXaZcoxdUgt8stZ2GL57oOvU7dS9l11nd2sY706 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, 2023-10-03 at 13:19 -0700, Mike Kravetz wrote: > On 10/03/23 15:35, Rik van Riel wrote: > > On Sun, 2023-10-01 at 21:39 -0700, Mike Kravetz wrote: > > >=20 > > > Something is not right here.=C2=A0 I have not looked closely at the > > > patch, > > > but running libhugetlbfs test suite hits this NULL deref in > > > misalign > > > (2M: 32). > >=20 > > Hi Mike, > >=20 > > fixing the null dereference was easy, but I continued running > > into a test case failure with linkhuge_rw. After tweaking the > > code in my patches quite a few times, I finally ran out of > > ideas and tried it on a tree without my patches. > >=20 > > I still see the test failure on upstream > > 2cf0f7156238 ("Merge tag 'nfs-for-6.6-2' of git://git.linux- > > nfs.org/projects/anna/linux-nfs") > >=20 > > This is with a modern glibc, and the __morecore assignments > > in libhugetlbfs/morecore.c commented out. > >=20 > >=20 > > HUGETLB_ELFMAP=3DR HUGETLB_SHARE=3D1 linkhuge_rw (2M: 32):=C2=A0=C2=A0P= ool state: > > (('hugepages-2048kB', (('free_hugepages', 1), ('resv_hugepages', > > 0), > > ('surplus_hugepages', 0), ('nr_hugepages_mempolicy', 1), > > ('nr_hugepages', 1), ('nr_overcommit_hugepages', 0))),) > > Hugepage pool state not preserved! > > BEFORE: (('hugepages-2048kB', (('free_hugepages', 1), > > ('resv_hugepages', 0), ('surplus_hugepages', 0), > > ('nr_hugepages_mempolicy', 1), ('nr_hugepages', 1), > > ('nr_overcommit_hugepages', 0))),) > > AFTER: (('hugepages-2048kB', (('free_hugepages', 0), > > ('resv_hugepages', > > 0), ('surplus_hugepages', 0), ('nr_hugepages_mempolicy', 1), > > ('nr_hugepages', 1), ('nr_overcommit_hugepages', 0))),) > >=20 >=20 > Please consider the above failures normal and expected.=C2=A0 That have > been > this way for many years.=C2=A0 Sorry for any waste of your time. >=20 > Of course, if you would like to look into these you are welcome. I'm not too worried about the test cases returning failure, but having free_hugepages not go back to 1 after linkhuge_rw exits looks bad. In this case it appears that linkhuge_rw simply left behind a file in /dev/hugepages when it died, and removing that file returns free_hugepages back to what it should be. I guess I'll go run the test cases without -c 1 :) --=20 All Rights Reversed.