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 0EDD1C48BEB for ; Thu, 22 Feb 2024 03:55:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 994E06B0078; Wed, 21 Feb 2024 22:55:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 944E76B007B; Wed, 21 Feb 2024 22:55:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 833F66B007E; Wed, 21 Feb 2024 22:55:56 -0500 (EST) 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 72AC26B0078 for ; Wed, 21 Feb 2024 22:55:56 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 36BE1C025A for ; Thu, 22 Feb 2024 03:55:56 +0000 (UTC) X-FDA: 81818076312.11.6BA4CDF Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf17.hostedemail.com (Postfix) with ESMTP id 962A34000B for ; Thu, 22 Feb 2024 03:55:54 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=FUkXK6xe; dmarc=none; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708574154; 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=YjmVoGrH3NTj6e8OOlyRDduZNWEtTAuI/cfYREosE2I=; b=AK4J2HvgAgDkIcZ73ou2vaIDGQgFeKnce1EMZnnyN91x18A0j0HnAEfELdZRZe9LmSLk7W mfLLPWthJWxmwe3aSA9QliX0mN8s2a3Vydf8ra6dyH1L9bifObYpMjg7+2p8Q4pSZzdxkG QmfKz/rsnQDZiF29BhjeXuKobRzwbX0= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=FUkXK6xe; dmarc=none; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708574154; a=rsa-sha256; cv=none; b=fSr26DHJJ/9L3TM8/LQd4lqljpMj0LReijS9bYZvb3nwC0gS2EKjoy0lZD1QSlaLmtGNef dZY9E1mTskdjGwxO69Va/AMPl8dvDkN7g+0Cc/2NK/Zz1q07ShxFzi4HxelfgSS+Vfo3Sq p4B9vyQlEq+atZtLHYcTdytI8gT4ydI= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=YjmVoGrH3NTj6e8OOlyRDduZNWEtTAuI/cfYREosE2I=; b=FUkXK6xenP/WwXGTFSY8g8oMOM kwt6CKjSWezMIKkj1AuIg/S4MApsDp3bLm/dah+8hAJRij+n677qBlbN8jxzHsNlx4Ae9uga7uqrp gZZ9AYaTTEzuLpIOpSIb8JPDbJip18pc0Pg6TZAfQXXDROk68N75nhEt+ifxVSF1ILQKJryXzWZzn RZ40oYCdzfU3BK5hJt9o3ALqnxVuYf/ZGbpduC5daG/DprpS2MqDSbP6XOTp5UAGVOtF4DWEiCCgM nsqKJmMdIWHY0GgxaB7uJ5E3lS0ivim4ai7Mj0MqqOWxzEhIfCaJZmQSmDrXaLV2qPkFiXRCUmpL/ cgVt4H6A==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rd0Bc-00000002Vak-2wMk; Thu, 22 Feb 2024 03:55:52 +0000 Date: Thu, 22 Feb 2024 03:55:52 +0000 From: Matthew Wilcox To: "Vishal Moola (Oracle)" Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, muchun.song@linux.dev, Cyril Hrubis , Jan Stancek , Petr Vorel , ltp@lists.linux.it Subject: Re: [PATCH v2 5/5] hugetlb: Allow faults to be handled under the VMA lock Message-ID: References: <20240221234732.187629-1-vishal.moola@gmail.com> <20240221234732.187629-6-vishal.moola@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240221234732.187629-6-vishal.moola@gmail.com> X-Rspamd-Queue-Id: 962A34000B X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: zskng9rrnscs3nqshu974uifoeh1ekhp X-HE-Tag: 1708574154-580650 X-HE-Meta: U2FsdGVkX1/oTPFerCVdJNlSh/FNLFdSdPurBUaY6p3yRlib+oIZZ8DWpvR9C7oe4dSZXE6pz2JSYwTlFY14qZkIQ2JKHMGYdlsdRNhw52JkPcybbJQ2DzghXcu/S8Upa0spSb3dq8XiGEwNVIzbUwb1Bg7EvN4yxjDknYbrtyZbvdIFzlQZIEXnjwpZffa9E3pGFPnLwcQsqo40+jMznq1EJvb4vqS7feVc/Z6HOKsbOdSH3uOWRkY5DRc8KLCorgC4lMViDcjB6MxR1ai1LBeiRKsMkPuXOnFNpoYcl8Me/s1SZuyOUm3v9CTC8OZRPv5Gd3KXR7AFLOThfOBrCUbS7HP11QhxI9c19UTNZ3b6xL5hwaBHJWf6+S+SCDhmx1lmFM3ziV+HuHiDN0vJHXdHcpMIwqKuTDB1Mv26zpsAHe80TiODpnka5hqV0w9IUbroB+qIVzqws66XHR/620/DrdbwSumaWsJgz6bqdcylh/Bm/fICpDPtR75k6rZxGUynKkEm5gshW46Exm99DYCwnj3FJQ6vEklBJixjzt6ByaqURzwPv1uhrOeD7iFOBUWKANsNlVa4eTFut0sdNz/h7aXQCBKXOsUp0DpNLeW2F2BY3ZvVw03QmJboCB/UsWkZbZSd+3gZjETgSGDnWx+sLBfITWwgCKVGksFJcSoTfm29YmBgh10LieduBNxYkbPwsarI412+lwVUp5qiG89wmXOtmREr+QJsocCLfBrvOBfmf/LePoJUG8LuGTpLHiB8xwftUYIlx5cLdOCw+s/VDqPkcEayS68bxyU2tTnPiuPmRwv05R4vsjeqBkAPsb40Eg+U1AJPU+/tWGHsySrVnWZtPogRWVVqi+yZPmRFnS519z4lg/RxcjV8rlI9/K+U1rd/4QCNEddaz14YbeKDZKlxweOMOSd1vBVdzaRV/uQyCH0vOkVCF17/XCTxN0mDBeDzPvLFAyFINq+ lZAEnKiK CYJ1C4IJAw8uo6qFMTQ0L1K5e93ZubpsQSvSPPzy7qaKXaP2c61CsKC909ctZOUB/2F2p725oxHZON3P59NFBklDY7eNSEwHWD/tBO2FpTxX4WvwBV7msmI+mpBU9CFdYJqT/GkWcREbFUonKXJuqqoyRspFttmCdSjTroWVqpyG+JXv1vrBBYCiI7PrzlcjMRjmbREEW6UL6N29IVBaLg0Gecnf71uaqz2DWBhT/LjiqBy0u44RHgckTPW/BjD8/gGsu4pC4t/FWnSn7NXbIzkC4VsY14/eawdIH 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 Wed, Feb 21, 2024 at 03:47:32PM -0800, Vishal Moola (Oracle) wrote: > Hugetlb can now safely handle faults under the VMA lock, so allow it to > do so. > > This patch may cause ltp hugemmap10 to "fail". Hugemmap10 tests hugetlb > counters, and expects the counters to remain unchanged on failure to > handle a fault. > > In hugetlb_no_page(), vmf_anon_prepare() may bailout with no anon_vma > under the VMA lock after allocating a folio for the hugepage. In > free_huge_folio(), this folio is completely freed on bailout iff there > is a surplus of hugetlb pages. This will remove a folio off the freelist > and decrement the number of hugepages while ltp expects these counters > to remain unchanged on failure. > > Originally this could only happen due to OOM failures, but now it may > also occur after we allocate a hugetlb folio without a suitable anon_vma > under the VMA lock. This should only happen for the first freshly > allocated hugepage in this vma. Hmm, so it's a bug in LTP. Have you talked to the LTP people about it (cc's added)? Also, did you try moving the anon_vma check befor the folio allocation so that you can bail out without disturbing the counters? > Signed-off-by: Vishal Moola (Oracle) Reviewed-by: Matthew Wilcox (Oracle)