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 2CCAEC48BEB for ; Wed, 21 Feb 2024 17:55:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B4646B007E; Wed, 21 Feb 2024 12:55:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 63D906B0081; Wed, 21 Feb 2024 12:55:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4DE2D6B0082; Wed, 21 Feb 2024 12:55:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3938D6B007E for ; Wed, 21 Feb 2024 12:55:25 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 086E4406EB for ; Wed, 21 Feb 2024 17:55:25 +0000 (UTC) X-FDA: 81816563010.05.FA07D99 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id CD35E180030 for ; Wed, 21 Feb 2024 17:55:20 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=UovlAaKW; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708538123; 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=wRp1w5Zyb5jyGjRVjFlb00/lPh/g4wKdCacDA3p0w8g=; b=Eu34mkxgj1siu3pODavs1RQC6aW26z25nfCnEspVw4CYOR/3kyDJdiybpbVIMkmTp9ltZ/ UkzIGqSLclB1ii+lr9SYqVGjqCTTPyvKHKz52i7QdSpP/V6CO7rIjcSWVKbO/1RC+oNL6L Y08LxGPAYnaD+hI6G7QUNZBCWaKKOvk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708538123; a=rsa-sha256; cv=none; b=H7wJmgSuAg9xNPXwtQY7Hw8OqUQXSzxGBYcZB+gYzyzZIg0AYJ/jymITitkHVdpP9cPFCe f6YJ8UGd4PRMaK8MCdtcr3z6T9bpeRxzEo6qgT7RUCCCVj1SGH+vEVu9r1LDJZmzG1eCob KcHWwpqW6Lmn3unlPD2sdYsX139dUwg= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=UovlAaKW; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=wRp1w5Zyb5jyGjRVjFlb00/lPh/g4wKdCacDA3p0w8g=; b=UovlAaKW6CTiINlkME0xjm1y/g 016q0sdMdEI9eGIVOzP13bTWo4rtMN3kwiwfvKS1b3JAacPz8zTuAioBslASuR3clZVqXVYYVImfP lPvHgEot5y1d0w2kiUe2SZtzCAhYAVQDHbGHztUaQBbUGFsaHYkfftJSVqvvInmFtV+qHqj0+fCiK dNw9dgVwOp3Wgc4K247DECSAhadEBSJ1HsFuxlbFkZEkQFmZRe1pqBmxumbMnkNvPXth416tI+Kno KZ+yz+geZhDXPZ6PYfhomxGQyqBhQLXIdpnEuue5dGy1o+Y6hAeWZFuX6lCLAkUUZb5IWcXL1fISe kgtXThPg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rcqoP-00000001KuE-3Xc7; Wed, 21 Feb 2024 17:55:17 +0000 Date: Wed, 21 Feb 2024 17:55:17 +0000 From: Matthew Wilcox To: Vishal Moola Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, muchun.song@linux.dev Subject: Re: [PATCH 2/3] hugetlb: Use vmf_anon_prepare() instead of anon_vma_prepare() Message-ID: References: <20240220231424.126600-1-vishal.moola@gmail.com> <20240220231424.126600-3-vishal.moola@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 8by1w76yzis8r3oq6cysabwamrhsn663 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: CD35E180030 X-Rspam-User: X-HE-Tag: 1708538120-821554 X-HE-Meta: U2FsdGVkX18x6au18E51PD6VkTPogXlsWqFZo4w8iHkXuNVdV16z/aWa4mYhQhAxvGdFUDgsHtkDak8vdMgowwV8yl0KlqgkZovLmbH1Z9As4zqgmr2+VRvb5+vErtF+ko6AIJMd8lb+PRBHRzs85jHiO4O59XFBzy4ZlGONg5R4xF8sXXFk76E97MY1N+Dvl/3XEG6Zw2kPrbvB6E1LlRuFubJ69YsWABdOmdBLge9CyDSyxcMRAHQqT+31tbULVve5RIdyBd9z82h2GGF5uglQ6hK7Fa9F96lm7bRIU2//TpjfTZtQlPuMawiOKSMtDvVmP63N4rQ4YjLqL0qHbuc5BlW7+qAkSf4ryTDCE+UoyEipcB/rxfXvB9TElAhIZ9OHE+y/DI8ajlHyYD29jb0d2NCdhLGr30OiALbQ0OIb3ib8jGnnYjBi5VC+S2fAj8b6Gbv3IeO1AH1lJ0o+H+ww+LMMY+Erd9+TFIUY+PzToVmB3Y2zoNM3GwycVNjmfcS5YKwgRZF2k5w3u08NdhxX3w3uOWYjV6o6YTh6ICcRrj0ZGgbl/IlBgYZsPng7YDOZuKAIHKob/xxPA1UYPjoMep7W3HkrNgNbdAeHy4Cusb4hdKzj/6qMYXWNGaQB5SVikGAD7fOX+sgF40Fba4JAo9uafzMlYb9gwRToAOd/PWj8DveMpcQSm+BFmJ33juZd4Za9ZSzIGBF3LjS12pBIfqKHsYIZMQHgX1CHeirHImwz8qa9onSRy2eFFzOnwrIVyLBqkEyhFVhh96yzX2qwpD+/8vSi89kdyjoiYkg/U6HxEYTtpMzXYSrtYgbPiOt7/61yhdMqLdanIofZaEnbMtETYO3QhZVDrkL3D3LXAqz8JkLmD8rd9C8nswDX+REcVNinc9YgaTenhcT1MtDvx/Ca7o+DEDREjOO+3R43YlNTUIDTDg0Ht+RpY5l374il8NjY2VY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000007, 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 09:15:51AM -0800, Vishal Moola wrote: > > > unsigned long haddr = address & huge_page_mask(h); > > > struct mmu_notifier_range range; > > > + struct vm_fault vmf = { > > > + .vma = vma, > > > + .address = haddr, > > > + .real_address = address, > > > + .flags = 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_userfault()? > > 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 conceptually > different. I'm converting each function to use struct vm_fault first, then > shifting it to be passed throughout as an arguement while cleaning up the > 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. If you want to do a cleanup patch afterwards, you could hoist the vmf creation all the way to handle_mm_fault() ;-)