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 89AF4E6FE3E for ; Fri, 22 Sep 2023 14:38:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E255E6B026F; Fri, 22 Sep 2023 10:38:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DD5926B0277; Fri, 22 Sep 2023 10:38:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC5ED6B02E4; Fri, 22 Sep 2023 10:38:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id BE0156B026F for ; Fri, 22 Sep 2023 10:38:29 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 71FDC8011E for ; Fri, 22 Sep 2023 14:38:29 +0000 (UTC) X-FDA: 81264489138.13.950FC2A Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf02.hostedemail.com (Postfix) with ESMTP id 43C498001F for ; Fri, 22 Sep 2023 14:38:26 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=none; spf=none (imf02.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=1695393507; 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=y/ys/EIBCrZHOHuYeAiNFtAfXIOqMe7/gZqe9qAsNq4=; b=dNJ5EF3l9D7AUJOaYNRHxYzNU9s9RqMDJ0QsWft2ZC9U0Ps1fjsEg2ZJ873Ril5D1ALURg pxzlSV+PnCMODEfJDdhCXXEAx/Dc3Te8WxU3tDGPrK0HO6GhDpeWdBHa1wgcmsYK45yrJ0 EIKfa4L4QgcvzsArGIRc9qmXR4Q9xYI= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; dmarc=none; spf=none (imf02.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=1695393507; a=rsa-sha256; cv=none; b=iqjNP+6KJ+7Eob/gwaNYfdo9sS+492X8v3rjLxpnNUJ8HtEnRfewy2L+8IrXindtIB0RdV PsIHsvyby7YiUSVZ5HyPztpkfNMBRdUZh6GOcbkOglX4sLRLMYesOF5nc3Pt73wQuDgYOs Bv3KN3GMDvfK2liAuqd+55HCTNhiuhU= 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 1qjhI3-00082q-1q; Fri, 22 Sep 2023 10:37:55 -0400 Message-ID: Subject: Re: [PATCH 1/2] hugetlbfs: extend hugetlb_vma_lock to private VMAs 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 Date: Fri, 22 Sep 2023 10:37:55 -0400 In-Reply-To: <20230921224201.GB21193@monkey> References: <20230920021811.3095089-1-riel@surriel.com> <20230920021811.3095089-2-riel@surriel.com> <20230921224201.GB21193@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: 43C498001F X-Stat-Signature: nfa511hwhyubbfyswfyuunpxcoxu9se3 X-Rspam-User: X-HE-Tag: 1695393506-207501 X-HE-Meta: U2FsdGVkX1+cbv1u2ZBhtdVvWI6AFdGUqo5LqcuMbX+qDfeKQWTqsSVqg+46IQ5YdqAiUvnqk+uRsuYbaxTx8Q+FfhynhsJ7rlEedTORLN9+jC/MyDhtacq+IB/Jk7pm2T1171v3pnZaN5y1DoGALdTniqbSQ4E4CCl24zuXsQ6t2kaxmkjWvs9VrzUFN8dYlV7aWC0uggouYBU0sxI+MvqVZ1/RR0oyEeO/U0dn+eVF2ijjcwe+S+GbdONVHpVlWs2olFRaNzfkzluRCO7oVrPQna8fI8TMeVUwJTxngExC4Ov2RPsIt6hE2InUa7ZsTUnl7TgOFrrcQxJ7YlFLZVsfrXCG3J6KKOmIlew5G8CsUIx3oMRh0FcncDgPcyEEvrCyXtIZjWgAxZXnZHtMK/gPGp/KozxQLeGPBFdA2ixNfqabMDIVpv5LhfcPpm6aTUnVbvh8AbJsrdzX2m9hvYAdArjH2TE9/IsfQt/R04ipkjjUks7RbDWkT3Yxo8ps18IrAbvw7D+z8uHhnp9lPVj7zUavvIrkskuXnpeZyEehr5+hEtuvMAhEE6FE1b9Sgsc5rLjEd5k8dywid3BXHPzASGxEShJBGVkM30mSrA21fMC5vKxjNqn9EL3aYeKkl0rch6iR3OJ0MFCVruW9+Xis1FQZGXFx+iArmUTrqxwMI/AnljS0G98TTPLyTSmUpkztGSbAzS0Unuiru6pbN6oUmmmT5ekSBmBBZHLhhJ58lHUzbt3BEYPI3zdXoss1BSWFAM+PoLz3oA3jpR9CJXG3uLTbvKX/3pe8mAuPph2Vr+/rqXgxLU9J08fz6cifixv3myWRdN3gL5xTw+c9hQj25V02hbA994S738NWBRkbViCSxmmFmiDl/a7W9vcOQ8OrGkZhPatdNKispCURpiDn4uUInk8DPpYpb/LO5FqM5GYF/ZV4mBssEhsmHanI7SmSGbRjozVWXPR4wrj uWZIFhsJ A+xIm9laz7tP+wntAy68w4f1T+837Xv8xP1K8aUioJ6d8oufoN2rYjtQvyXeW9bfdsihTI0z6aXWHja1f9Ilfb5Il+o44RQzPZeE2mbBydalcOWh9lGeA9P85JkUuu/oJ2SOhwLZgj+abcDkbibKAZMlJiVnkOW5f3pzfB7Tx66dXGeo7uzwc50fjonfXucCFMRhDEwgBAFmieXXuzmjxsn8IJi7XK47Sf+sm+zoTECTlUNXWs0JuMqryiiwtJnROn5KG8xl8D330ROzAcyKedNg+Q0eE1KIArW+nYTtCwo8hAr2tSjTV1YfVYfWPmoRqyL9fyTWPnUDem4l0lYx/7IAWn1nYP3doXN0LO1W+XaSyZl0HzkPzhTLuVg== 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, 2023-09-21 at 15:42 -0700, Mike Kravetz wrote: > On 09/19/23 22:16, riel@surriel.com=C2=A0wrote: > > From: Rik van Riel > >=20 > > Extend the locking scheme used to protect shared hugetlb mappings > > from truncate vs page fault races, in order to protect private > > hugetlb mappings (with resv_map) against MADV_DONTNEED. > >=20 > > Add a read-write semaphore to the resv_map data structure, and > > use that from the hugetlb_vma_(un)lock_* functions, in preparation > > for closing the race between MADV_DONTNEED and page faults. > >=20 > > Signed-off-by: Rik van Riel > > --- > > =C2=A0include/linux/hugetlb.h |=C2=A0 6 ++++++ > > =C2=A0mm/hugetlb.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 | 36 ++++++++++++++++++++++++++++++++---- > > =C2=A02 files changed, 38 insertions(+), 4 deletions(-) >=20 > This looks straight forward. >=20 > However, I ran just this patch through libhugetlbfs test suite and it > hung on > misaligned_offset (2M: 32). > https://github.com/libhugetlbfs/libhugetlbfs/blob/master/tests/misaligned= _offset.c Speaking of "looks straightforward", how do I compile the libhugetlbfs code? The __morecore variable, which is pointed at either the THP or hugetlbfs morecore function, does not seem to be defined anywhere in the sources. Do I need to run some magic script (didn't find it) to get a special header file set up before I can build libhugetlbfs? $ make CC32 obj32/morecore.o morecore.c: In function =E2=80=98__lh_hugetlbfs_setup_morecore=E2=80=99: morecore.c:368:17: error: =E2=80=98__morecore=E2=80=99 undeclared (first us= e in this function); did you mean =E2=80=98thp_morecore=E2=80=99? 368 | __morecore =3D &thp_morecore; | ^~~~~~~~~~ | thp_morecore morecore.c:368:17: note: each undeclared identifier is reported only once for each function it appears in make: *** [Makefile:292: obj32/morecore.o] Error 1 $ grep __morecore *.[ch] morecore.c: __morecore =3D &thp_morecore; morecore.c: __morecore =3D &hugetlbfs_morecore; --=20 All Rights Reversed.