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 DF81DE7D0B7 for ; Fri, 22 Sep 2023 00:37:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 525826B027D; Thu, 21 Sep 2023 20:37:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D6346B027F; Thu, 21 Sep 2023 20:37:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C46C6B0280; Thu, 21 Sep 2023 20:37:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 2D4C56B027D for ; Thu, 21 Sep 2023 20:37:34 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D415740783 for ; Fri, 22 Sep 2023 00:37:33 +0000 (UTC) X-FDA: 81262369986.29.4FA77A1 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf06.hostedemail.com (Postfix) with ESMTP id 3E07018001C for ; Fri, 22 Sep 2023 00:37:31 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=none; spf=none (imf06.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=1695343051; 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=l4tQT7a/FNykT0IYOZw/PDyBhOxLV69qAXcNEHkdaMY=; b=2NnbKdXNXz1t4AAiM+EG4aYLTRbjwmRqJnrh+/lQRmHSAp4mnnIxGRqO7o/k8e5qXjVBV/ 9s6XudD1RhCviSJkuRzDPA4MwLq50pkwhDQLc91qYrZq33IcjZv+avsbkwXi/rwqWFAss/ QEwmphH07Xj+XwFDgV6cgGaPH0/xTQ4= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; dmarc=none; spf=none (imf06.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=1695343051; a=rsa-sha256; cv=none; b=IMYGHpB1Zl/SqjR5gIXSzBjfh7r3hxmNdgdTlOgbf+B2E+moTtgopSfzX+x1LXs1wKdrWc BS+ZxYbYmQ6+CpQOTA/+Fc97Nyn0rjwaeqncdkVx1CdeVSooY6MhR5fDpeHkZ1+Jysfq2R IGIiz4q9SyZXCb/qiOStTtRPN+FtG/g= 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 1qjUAJ-0008Jc-2d; Thu, 21 Sep 2023 20:37:03 -0400 Message-ID: <42128925a9c36e7bc9d55ca422e36ff880999087.camel@surriel.com> 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: Thu, 21 Sep 2023 20:37:03 -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-Queue-Id: 3E07018001C X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 8gquguzcr6xhrxhtu3w7f4wfi33mt8u9 X-HE-Tag: 1695343051-61400 X-HE-Meta: U2FsdGVkX1+4fB95W3ix1krttudDK/RAcqnJlPUpsaoPdIj81LnX4Wv13WdlsJVxHNR1lo3QZ7ZQwzxCvZTbciTvxx5oOoWhDGX+lMUptcHplbPZ6m/9UFH5TqOBxOCTaC2A9GVinz16C1Np+6EWaHWUtvIzAw1gi3csUlKwa5vXknP9+A1sJmANlPR5fW/N4Pm+sD2iKEij4ITaA45OVGqF5n4NQzTp50/3pKQ1wf0hQKKtrfEVYIvEOewADFuDeQZmDZO301pD4QvEQV/YTAsderTkRBWAtDIKcoJsB2AzusuSyKM4e4SO4C0EBmswHAFW2TBNr/8yxag6bVtL/sRdqaWMoOD3dMzLs8nSjfV4MDT1bHB+CJHCgTkghbcILsZPHfrNWEcJWvzeIlZ4XlYg9GVsWnM709S5Yjdo5sxgk0c9FZfVLE1RmYrPrX4TsQigFgEqVsGUaPurOvqzKiQQMqjmuqm+AoLLv2GmVAWvb8t9VGqHAu0TxwkXExWRKG+6xfDOAU2CYp7ONc+m+mFT1y/qNSZj8Sqn9hduy1nIR9Rc7ASDolWwc+W6onuN7IfGS6mMJipVjnuQ5VYsEcHW45Te8I2g104SC39GKlTsuRkbj0Lc033eJ7l3qSQRxXyVQklamLIrHYTrkYap2SbF8xQCdogAD+TRT8cMcrtuMHXZHRgqBGIjimi1Sw7CosI8mCx3qs4UQlCfKRqhS0YxCmZz3E6hX535Xr6YUY4//K83Ah4/o/qqS+FuyfbkYgJ0Zy+2zPZv8DO0vKOJaRtgPK9K8vpSrY38zTPxg8+Rsxqy4slBpRzVzsYYlqojcMd7YGrgGPzyE5YxXfWfD/sL56ai0G357kF2g2x6AZnGtSPBO71tp2x25IqNAj6WhHBK9fFLRus8MLB/ijwsTEvsnAXcQbM8zyLT7mssxZwPp0lxb+glQ+z8TyZCsnh7mpQa4XaM8EgjK3O2EC9 uceHmhes VJu8/meYmKjvBBuVGvEkdktbY/TaYBA+ujnFTb8VN/ADHRycmlEjVbnsQ8sIokLN1hI4di9tFcMoBZuoeyQtAdRc6lvIbeokC4XcAFQL5Cv6f3d4H2+JRKQpRyxPFsB4sP9lU6S+NJ6ffv4KXIgSh+NAIVhm5SaBV6IMMhtreYKhzA4v56dIPF5XNIHqAtqSnJqjE5h80UC3BeDwWZW7RhwHtVQGTLf85PDi1fIBqhayGruCZm26yJQ0UamDLPZGFl9OSlwXD+m2r44vGbrEN77DMImS2AEc+c2RoneX+WXen3hk9otMlHVM8cmeJn+TsAdiAwpB9j3/mCq7+FV3y9d8ttqUzwwT/oWZlMbH3y6vUPiZV4V8Kj3mBOg== 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 Ah, so that's why I couldn't find hugetlbfs tests in the kernel selftests directory. They're in libhugetlbfs. I'll play around with those tests tomorrow. Let me see what's going on. --=20 All Rights Reversed.