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 07434C54791 for ; Thu, 22 Feb 2024 17:27:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7FEA96B0083; Thu, 22 Feb 2024 12:27:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7AE976B0087; Thu, 22 Feb 2024 12:27:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 677526B0088; Thu, 22 Feb 2024 12:27:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 590C56B0083 for ; Thu, 22 Feb 2024 12:27:14 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 0DF8740BE9 for ; Thu, 22 Feb 2024 17:27:14 +0000 (UTC) X-FDA: 81820120788.06.09D0C78 Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by imf24.hostedemail.com (Postfix) with ESMTP id 4A12D180007 for ; Thu, 22 Feb 2024 17:27:12 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZH6rdZUb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708622832; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=QuKAAfod1MzHS/3JdjwE+h9Jo38lBcZP+cEWXxDIKks=; b=P83byVSTNJ6kYYV9bQ7Gf8QOZ6xfHJzRcbRAWltwAjv69jX+XDFvIyxCPg7pFTAUxeP4Bh 6WRmlzx+0Ek5DmITZ3jKr6rABlmlqLKGCN5E1oUwPZZ3XIrFDT4akq5yUgUSX+j7gJWldH zCIcWF4bpXwtkFwwoCTIlz+gjcQ5oHw= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZH6rdZUb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708622832; a=rsa-sha256; cv=none; b=wT8ZuVQOBWpuexgOePjM5CxLjLhuU79vEuEcYjeLeJ5/tzM9NgEHAE4mdOueMfoKJC0Pep DMmN1iKNgILmL5D7vdTLuOe5uzqPDc3UDfFpWNdVsU683jzdDCvOL3rTNtIn8VantSWgtt iOv6ZEavLGz0d56OKgq46X7AgCtuVQ0= Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-6083befe2a7so49179557b3.0 for ; Thu, 22 Feb 2024 09:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708622831; x=1709227631; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QuKAAfod1MzHS/3JdjwE+h9Jo38lBcZP+cEWXxDIKks=; b=ZH6rdZUbsMSKlk7XDYf3ikIZOWTD9i8s2uj3U0mEDK4UaeR2NHFGyn5idhgfNWfCyL ZCWFPa965mEGcbVblvBRI9IOPBhs/hNfT6zspehZe4TodHvicp6W1XwyT6UPNcPiy+My 4vFMw24RymC2GQ0eC4OPtgnQm9ixk1Vha9S/ExnW5wSEi19o3Zq7inks7Nrae4WK4+Ew 2Dpt3ikbgCq+207iCR1+HSZrrDZzwOYTiSTA3gXqrncqkOmeeJVAQZvELXY1+kqKC5Ij VzjfRYsnj4dm1da0w/Abf1O3KmpBif0u9e/Vf0ZhioVbmgBPLrC9FEG3wBH6VjsXDQOx bRdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708622831; x=1709227631; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QuKAAfod1MzHS/3JdjwE+h9Jo38lBcZP+cEWXxDIKks=; b=wtkfp1ws/cnnV1npwQUWoJT3QaPYEcJjWJuTb+LABzuEPzd6WwRJN7KW4sprw/b7NR icev+2PA1IOWCNeARbAG3Sk5yH6ZbyOa8yu5WS63YotvtX7SmKWmqRf/rC9hGKy/32Pf zxRY2vdBz/f8Zq5dwqXl7lTr3OZFLryyaES3vO1uNIHOhbPyCKz5nU6irfqd97BZOIfS U9psi9dSyD5zOxDsKGtp+ZHEloxeFU/7PEQKe7Le57s0qq3Zm3c8l0xGfgcknoAqWlDM saUg9ll1jjrh70iuyeb2bU4Yvadt74YfgDpNH5FIz7PnqnX5iQ8sRQAzR7yuwhC0CyKN JzMw== X-Gm-Message-State: AOJu0YxODo6Q4AkqzZnhkvHUv04ys0SY6UeHCy7Kil18+t51KmLvkkd5 OHRBj+0KPUDZPaqk8A26yMlLukRngBSdq+fvJJi7MLFxZ98kwJi3+AX1RGIWcop4PniEi+Jus0i 4Au7EjfVS/wfwkgu2n83wRUg7Pxw= X-Google-Smtp-Source: AGHT+IHO8x0tadUdaQBRIMWwUXYyEOVeTnOcoN6TwMUV/UtT8moscekER2ZVB4LuPbM93z+Fy+yJhn0cyDA7Zdk1jiY= X-Received: by 2002:a0d:d984:0:b0:608:b193:5a3e with SMTP id b126-20020a0dd984000000b00608b1935a3emr555773ywe.32.1708622831338; Thu, 22 Feb 2024 09:27:11 -0800 (PST) MIME-Version: 1.0 References: <20240221234732.187629-1-vishal.moola@gmail.com> <20240221234732.187629-6-vishal.moola@gmail.com> In-Reply-To: From: Vishal Moola Date: Thu, 22 Feb 2024 09:27:00 -0800 Message-ID: Subject: Re: [PATCH v2 5/5] hugetlb: Allow faults to be handled under the VMA lock To: Matthew Wilcox 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4A12D180007 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: jcy6i5mm5671m74aebd7ohuytqraue5y X-HE-Tag: 1708622832-485392 X-HE-Meta: U2FsdGVkX19djTw8frwU/2iEURiP94EdRizaoRGHLFeIMhR5IZBx10ec/0VPNjaxCuHYQwDefBpFDa1EaMdhMwz7jBzdLOnbr7BffTghBwXggHOOGOnvVTl4Igt7/PEkPnEObJADVK0K0BYLeRssjARw1cgLC2EC5ecx2pN0OAPdB2LwPN40Uud2dbKmyGsJwda2Dzu5Px3VFaMpL0XWnei75Y5Qb1JpbWaggIfyscIGOZDWP8qM1P7Jtn7kHg24eND5F4gSVwzNUWp0D0ricmpxhHSctXd5UcXI1nBjoxLZFhd5k0idev0MCc7RRbruj2q5EJNxl2AAPUstZ7i8KXGVb1aLvA6Eh4GkxMKeLVutulO0eZs/LbdKqH70tfyTq4PQu902Epyqlt82UHqZHpX5NWk1evcK2cEYrrj6ezUAp5RT2zwYBJCxq80KFyMI7kLu45tjTMIJ8kgC+r15Vv8sdvpIUZ/VYHR5uFx8lGPiCDgK/dcjhkGkiTpe3jrDCo8183rwgbMTIXqM6YQQ5rfsmO6SbRPLlNF4y9TBpup+mKNlBe7WocetVO0kNHRrJM9f0vzoMQgjk2YnQKvz6jn9D6yLg/tPLzlk6u0LOyzXa/G2MM97394lPT0JwlJ5+3krICGYRiFj2y0MvSlUSjy3oH7M2p6srwxqBs3O50pEL/qjFqe+kGtjZY/HLBQWd2KuruCe0VgT2kPKE4VR6XdNr47S7orlUkgovqJR0q2GKoV0a59FHHVxPQzBZrN8sa3jjDjVvsvhdBwInBmrt6PJWZu2X/QpEVjhECOXJF4nfQ8PcU2zxKhT3LiDcPniOkEdxjsA4mV/r6YjwYJGq7f4LE9gbCN6FD85uVGXsu9JUGvZPq4e6iNjdlRVo9Phlxcw8rj1y5z2fWM50UJWcuRqv3lwArs3etKKe0sOj+i/g3cB39Tcxpq2gLaobqPIftMD3HZFVgvOQDk2TIu zFTUId3A c3KZHOUu70MDiIet+BOOP/d7vovr6zkSrnbwbWiGcPQcJQLVza/JufsyTLE/vLBvWdYAc/r/PmDb/Zwl7G+lNc0WpAcJDcaqtbEPyCHIQQP08msWaYYlbg6CcYnSvQD4parSsmHCngy5haSRg28dlxwj3U8vKm6TofQvzjEB3WDUvRlrtWMActzx2NS5rJXv5bQSD9QWz5mMF2tJqrN5EmXCRv8f+TUl50ouYdGVHrWVVRKH/7J6OcvBQHJ2/AOBZfPyjsxSABSZkjVECgcDlVg2t56ENebjsmI+Qt1L0d6xLZa4v+KluMcBV3mw12KKWww5cCSOC75+p+FdfNaXE1OKFLdGbnj0y5bcvzQygVJhghovdO1d0rQOTVNKt4xYEev2k8edtiQ8ZIpPHSf6f4xWEtlIscrLI+23qx5bAx6HQeb3d7ZqMLvwDZsfaefLeTFSNrvOXjPEBeJM2/obQ16YpxQ== 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 7:55=E2=80=AFPM Matthew Wilcox wrote: > > 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 freelis= t > > 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_vm= a > > 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? Moving the check before folio allocation occurs keeps the folios on the freelist so the counters remain static as expected. If we are looking at a shareable vma, hugetlb_no_page() does not need this check at all, so I left the check where it is. We could definitely pla= ce the anon_vma check above allocation, it would just make the code slightly more complicated - needing another variable (or reassigning ret in various places) as well as adding another potentially unnecessary vma flag check. > > Signed-off-by: Vishal Moola (Oracle) > > Reviewed-by: Matthew Wilcox (Oracle)