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 59AC6C48BEB for ; Wed, 21 Feb 2024 18:03:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD7EF6B007B; Wed, 21 Feb 2024 13:03:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A888D6B0081; Wed, 21 Feb 2024 13:03:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 94FE36B0082; Wed, 21 Feb 2024 13:03:07 -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 872226B007B for ; Wed, 21 Feb 2024 13:03:07 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1743240B5B for ; Wed, 21 Feb 2024 18:03:07 +0000 (UTC) X-FDA: 81816582414.09.FB89983 Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by imf12.hostedemail.com (Postfix) with ESMTP id 208C840021 for ; Wed, 21 Feb 2024 18:02:55 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KrGovu5m; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.219.169 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=1708538576; 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=IZ4ZIhOlLj482hbMZwIkVDjrXVuHvcX1vma+IQSxDL8=; b=KLW0Z3Chs3RVUPx1j1nEC/5g+Wsa8dZz4x5Uklb9D1AqA1D9ZGpWQYu4FtL87CFEGwgcIs 8pHwX5z+ZVAW84mjj5XOtPIuU02zR/C6BHVUSjUKz81GGGRLzXfkjISnhuShgv9SfwPead wBhT1YYzek/to6I8LkKJOw9CH1WlfvI= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KrGovu5m; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708538576; a=rsa-sha256; cv=none; b=sFrS/T7iO0mYfiGyzYMOQ51oHaH+6MckuYPyW+dyPL073AycIyKsRg3OqXBIwf3aJfGcJG kbopVglYpd+Vm3kCQht3SQBOMmgJ7/96AroV4tjvvFnMjCfsR/Bk+ZPTb6Oa9zTII8Na8v XyzZpunGsJBcWo8XmHYtuUidgLoql7I= Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-dc6e080c1f0so6544305276.2 for ; Wed, 21 Feb 2024 10:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708538575; x=1709143375; 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=IZ4ZIhOlLj482hbMZwIkVDjrXVuHvcX1vma+IQSxDL8=; b=KrGovu5m6caCmCTz5h1MYY/GemGREBMVSIEFiChDCDG/GeXoYlEAnb9hlcOMcsKDny 8hFaGN8Jr+IPTEArvK62UO0pFVJQvBmF7UePKbkqPiaBVaA2LqptrvGSTDFGuOm+8d3y 61H662RVzuiyhYEIbhb+p+rHt8ZgvDUUkWlB3EkWyr+SejF/vPFDcYclb5sr930vb3ap +4oKTUyCOrCje6peJ5nTnJT4m8SxrFReywrLxqhb09iYGs53GPEnpMyDIepnrRSWRTIf b+3ValAAjpZZ4t1tTlpjfWBa/jNeHcP2RpK9xwIU2TjVHiVBJVU06rsolb5jYK3dGaQg 9cMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708538575; x=1709143375; 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=IZ4ZIhOlLj482hbMZwIkVDjrXVuHvcX1vma+IQSxDL8=; b=kGUu6vNFIOnhpIpxw/pS+JnUhvwqsftr610RnvuiAUGcikn8B2AAMMypzzVduimq5Q c01ajunuYMCTdU/W9W233xpGMD2XMADP9Gro2eX6c7gj3zTU8evnq6KMRrOnDVgcM/rT 8e4muhuqMayM+gu+JIF44esRdUSouoxVi29NYZjkDJ4TRUhmB2tjZgDwRrEi+8EhaNXR SBkXDUYGMijSgg7Z4AFPgrIbKU2ANWktAcJh5/NT5nV7gzLPZRptLdoq+gcIWVY5wpxn LWwTCB0rPuB7dwr66BHsJ9dsZZOfSVnrfpe5PLLwx2dPwDeu4WuwLFYA2ksBivkI2UR4 xXeg== X-Gm-Message-State: AOJu0YzhhRK4F8PRo9b/nXQ9ZYcAvPiSUxD3ByOY5Blq7J0bl0jWyXaj pUcSeiHKtLYI0nmZzayehwrkptOYw1KHI6LDPw2sijv5nShazjiBvXly8UWotgyBQcagtwRAw3c auqjbONYYYCpzvSoIEx1SsMh7hXs= X-Google-Smtp-Source: AGHT+IF3eD0jXeGA8GC5jgAbnNJApudrAh14W8XoWF7HVCuDb0xyxZgSwcIAjE/svFpEKS9393R4xM06BGzr7Toj888= X-Received: by 2002:a05:690c:30a:b0:608:5216:80c9 with SMTP id bg10-20020a05690c030a00b00608521680c9mr9108775ywb.40.1708538574924; Wed, 21 Feb 2024 10:02:54 -0800 (PST) MIME-Version: 1.0 References: <20240220231424.126600-1-vishal.moola@gmail.com> <20240220231424.126600-3-vishal.moola@gmail.com> In-Reply-To: From: Vishal Moola Date: Wed, 21 Feb 2024 10:02:43 -0800 Message-ID: Subject: Re: [PATCH 2/3] hugetlb: Use vmf_anon_prepare() instead of anon_vma_prepare() To: Matthew Wilcox Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, muchun.song@linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 208C840021 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: gh4eeobqhq3bh7mtzyfwqd4ykab9ad4t X-HE-Tag: 1708538575-899523 X-HE-Meta: U2FsdGVkX1+rXvfwLjdWsAp77JzIpnlAu1hpJmBkngvmeMRr2M1IgDAbqrthYIrrlGar+p6VMM10XQ7hJUVZ7ztzl2qc7Wm3fkKk8Ue9NW6HgRpd/L3sNYG3mn1dv9UllB1bRotZkNOb7BX6OE/HG6Pv9P/BxoxDUyOu2lRcWqzOxRkM/4WZpzjOMVovGW25d0rX7x4U8nacaaLOcj4tLlhxTDfDI7Y4U4C6MbGPoAOiIYJGqk8MJLc0dC5XR4BDHVnRLBEf3Pm+srKJ823drQvcgeCxHD7rC8wFzXBmlzpSeMsFQurlZLrKfHKdPLkjmLNientqfVi1Idl6Mp0VKHmFnOtEntA8zgK2uIRl496i+DfXUJhsDpLa+Z5PU4B5V9yDmwfKnUkD9dYhaUMsc3AcIS1euqWTP7TMT6n0QektL2VjzXkzZ60jL2aodT/y8bemXip//qggjsrR6kaRJ0Hatn3pS/OKQ73DhVfeQBW3C8WqvqnJm2B2iPLJrUCCZx5uE3jDcXrgx5lkPURDfkBaLyBSddZgUyzeSDu2+5iNxFgnFQiuYPbWba1Wtev+DiIXY8vZZOHYaoVpnNwf/Jx9X77MOWQ5RiKzfQvqqDtv+0mafihg/KYGZDZjoilaK73dPN1K00Joqt7JOWTACe0sKdT60T6MIen79mTqIQUtX7+NSwQPVjwpPTx1ABbfUmYvO8ZJrRYeNflzL9YiEbG5KClSJFG8xnnPffVVJ1R/70c5RrHzM86OUBV6VS1sXSN6zzxZOc59xLaQkq0RUeRCFArPoQrNM4RorOb2IB8chjDUxytDUHkqcRtXxahDx7tPFDUi2y4Ccx93VXZs8Kbv8t0GXP3jX+28aYezRz6p3gB9/zWg74VzTOfA6uanx5R4nre4u2W6Hnfjlq/XDhYiFKrgXF0yI1v6rfC/P42Z6LZX06srysFkZ94zO8CFZdbjG3Zv38rLd7BaAsn F77/Sl6p yMVkq3AuQCxbPjPorRtemzK+A+J8v0cEk+LbkaS1TybSMEUdATtjK21Z71M4hfGx5QtmHR5fd6ONH1z/fsVrvFoCNDzCNXY7/yKhmGXRLVOT6yT/oKek7MjM5DAHn1qJiFGvm3ddjRhWjZkEqtdd5lXzItq4KOsK2C0OgjE+6+rYszQGLz/M1SUbtss2R4b892jQlRwMMAkcbgHYGNqxNUrIOq/5yZ6zH1KE2oBc61UbQ/e1dFo9cflkCdfYXmk6tjMdNFlkaJ1E71mfqNp6MD6la235cXf1ef9npuPzOCCqTEruc/wdZfwKfSjQ9BqvBkgBlHskv9loFUzQ+vthgmgx28oE8snTJU/jddfNKmDAdCUGxwNdeH15VWGGBjB13gBBVZaoK5ITboKY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.003724, 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 9:55=E2=80=AFAM Matthew Wilcox wrote: > > On Wed, Feb 21, 2024 at 09:15:51AM -0800, Vishal Moola wrote: > > > > unsigned long haddr =3D address & huge_page_mask(h); > > > > struct mmu_notifier_range range; > > > > + struct vm_fault vmf =3D { > > > > + .vma =3D vma, > > > > + .address =3D haddr, > > > > + .real_address =3D address, > > > > + .flags =3D flags, > > > > + }; > > > > > > We don't usually indent quite so far. One extra tab would be enough. > > > > > > Also, I thought we talked about creating the vmf in hugetlb_fault(), > > > then passing it to hugetlb_wp() hugetlb_no_page() and handle_userfaul= t()? > > > Was there a reason to abandon that idea? > > > > No I haven't abandoned that idea, I intend to have a separate patchset = to go > > on top of this one - just keeping them separate since they are conceptu= ally > > different. I'm converting each function to use struct vm_fault first, t= hen > > shifting it to be passed throughout as an arguement while cleaning up t= he > > excess variables laying around. In a sense working bottom-up instead > > of top-down. > > I think you'll find it less work to create it in hugetlb_fault() > first. ie patch 2 could be to hoist its creation from half-way down > hugetlb_fault to the top of hugetlb_fault. Patch 3 could pass it > through hugetlb_no_page() to hugetlb_handle_userfault() and remove its > creation there. Now you've alreedy got it, and can make use of it in > this patch which would be the new patch 4. Ah I see, that way would definitely be a lot less work. I'll make that change for this patchset in v2 then. > If you want to do a cleanup patch afterwards, you could hoist the vmf > creation all the way to handle_mm_fault() ;-) Yeah, I was already looking at doing that in the future patchset :)