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 B2F55C5AE59 for ; Tue, 3 Jun 2025 18:31:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B5E96B04ED; Tue, 3 Jun 2025 14:31:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 467336B04EE; Tue, 3 Jun 2025 14:31:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3558F6B04EF; Tue, 3 Jun 2025 14:31:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 11A696B04ED for ; Tue, 3 Jun 2025 14:31:25 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8EAD65F66B for ; Tue, 3 Jun 2025 18:31:24 +0000 (UTC) X-FDA: 83514932088.07.831DCB6 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf27.hostedemail.com (Postfix) with ESMTP id 0F2894000F for ; Tue, 3 Jun 2025 18:31:21 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=DzyZQ5pM; spf=pass (imf27.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748975482; 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=m1y2tlzKb/XIoTPJnqteiTg6x4ZTCSc+I1WD6iWm+kk=; b=VzM8PKosSoilW/UodWs75ypjfyKiDJFX4KKpT1k6VjCI45a2jV+8gpHPKxRlNPPvdtEVIg uy9m4tRzcrdWwODxw1g8CqQfX6fX7Zm1SW7EaCM5bAM8cJ9fEdpN+1RNl6+2cfWBzdNu+8 fcVoD3cwGCJ5X0BGz0x7wBeiyR6ky3s= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=DzyZQ5pM; spf=pass (imf27.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748975482; a=rsa-sha256; cv=none; b=LwzgJVHDYswk2+9UadDyez/FJABBWRWDs2yscqayxvSBt7dghCqdnkhc8oLfd7YJh/KdVK qvjY4GBAWJfEd1XrfV6JSbPnOvkfeCyMyI1/mx17eW/jbsGSVZhY7Grg4EOZsFsA4gAio7 xCFz/Im67toS9v4hGU09i9aWEHIHEWM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1748975481; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=m1y2tlzKb/XIoTPJnqteiTg6x4ZTCSc+I1WD6iWm+kk=; b=DzyZQ5pM4/dnF4ctY4azWm0WQMURZtCshJdEIYk902PyX2YMhCS/kEWeG8zd6pkWizkLbz oVsNPws9ukY8T7/aO8/xi6gWTgw0yqDw058qJiPsQkjHnlE4LcNfzS0H4JGksh6CKGUHwe VqSL+ftYNFhMu5EVgOknmdCny+1zXew= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-34-S3K8Gj_RNPCrYjfYqD2n7A-1; Tue, 03 Jun 2025 14:31:20 -0400 X-MC-Unique: S3K8Gj_RNPCrYjfYqD2n7A-1 X-Mimecast-MFC-AGG-ID: S3K8Gj_RNPCrYjfYqD2n7A_1748975480 Received: by mail-qt1-f199.google.com with SMTP id d75a77b69052e-4a5882b7339so33040621cf.2 for ; Tue, 03 Jun 2025 11:31:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748975480; x=1749580280; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=m1y2tlzKb/XIoTPJnqteiTg6x4ZTCSc+I1WD6iWm+kk=; b=L+ILviqCeTsmMRsylwFoTAVYR3nXdI5bjS/4CBTWkDwvUT4SruhAoxGk5NtKYqWJfB MwaubReyGmvZ+CT7Xljr5A+hFuuCiyGGiEFoPGheQukZWWdzsqGT6NLGxWE3SNsF88dL Q6tIrWvlnNJq0Nz7/uFl95Vy+kDGLKUSHTna2W8KU68my96igpbvAM2UHkQyqUmsBVT0 tDuMZidj9qUvOQ43trVqdyu32K4j4X3LMEYrT+ivl/9O/nAW4gzgoJc7ud/hjhQ1DcSM OXTyWwq++ZWAzupTGlunrMcusNgKFlE+wIVT1t0DBBdEn5NkwWIR8JT0X+ACQ+Fsd7a6 X8IQ== X-Forwarded-Encrypted: i=1; AJvYcCW+5Ppcndvg1CBzd8KcswIG1Iod9e+biNi7rxUrLRxmd0kEfC29N5/1obbf5GE4xS8/XdVECv3BOw==@kvack.org X-Gm-Message-State: AOJu0YwAr/TmKbLU2WcGvHExBCbah48lAwjie4XVBbT91DPDOlQ+EWtC jZnjzHVwGGs4qk0xiJN35NOpm3YCZszfPKaMb3B6IhkNWczzdf9uKExq9XQkArLwqY0vU3cLNqq 7mMsMGF0kl17PfCRNNTdUnaQTWY48yCq1KMx7jztdo1D4FIE30NRe X-Gm-Gg: ASbGncuFbqDFqLDT2az0bZWMnI995zHxV9+V2+LfttQRZ9Ow/1c2XhQ2cacoruGFYFc +se4In08ceLO4G8GYIv7nE4M7zLwua/4liykWBpae41LM5ql0tRNFwDEz/P8TY3BLyZ+tllFpQu ZZxPockpVRuYCv0VhybORYugN4F8XXB//l3MGryHpjqXDpJ/vda+8pat+5BsjthOdRxf/mWE5b/ Wa/TI713XZ1s0IGzclEp0gy1RKD8P8xFm8dW+MUS0W7gKyfYOsAYYl70ItEFNS0u/fmnTXPUoQg eJk= X-Received: by 2002:a05:622a:590e:b0:4a3:e3df:f9d4 with SMTP id d75a77b69052e-4a4aed6b1a8mr193643781cf.26.1748975479657; Tue, 03 Jun 2025 11:31:19 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFM20hRlMEpFpUHXs29edcNfUgwlZYFzZVWR++bT/y5MRek1KFlHKwVz1YmhrxFLgjZhAFOOw== X-Received: by 2002:a05:622a:590e:b0:4a3:e3df:f9d4 with SMTP id d75a77b69052e-4a4aed6b1a8mr193643341cf.26.1748975479196; Tue, 03 Jun 2025 11:31:19 -0700 (PDT) Received: from x1.local ([85.131.185.92]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4a435a840a0sm77609561cf.76.2025.06.03.11.31.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Jun 2025 11:31:18 -0700 (PDT) Date: Tue, 3 Jun 2025 14:31:15 -0400 From: Peter Xu To: Oscar Salvador Cc: Andrew Morton , Muchun Song , David Hildenbrand , James Houghton , Gavin Guo , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 1/3] mm, hugetlb: Clean up locking in hugetlb_fault and hugetlb_wp Message-ID: References: <20250602141610.173698-1-osalvador@suse.de> <20250602141610.173698-2-osalvador@suse.de> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: fRqvumcavfWoZPCHL-IamkDFlt5P0Eraj7hGj50rQY4_1748975480 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspam-User: X-Stat-Signature: kk6gs76netpt7ja3c1enfuh97f37ru6x X-Rspamd-Queue-Id: 0F2894000F X-Rspamd-Server: rspam11 X-HE-Tag: 1748975481-216307 X-HE-Meta: U2FsdGVkX1+LupGzsKFQxzlEnBsRPM8RAAgqXTFKlmtr61aG+fp4BmAgMPbpRJa6gOdQEblZw0q0syN9E6uSx06+nCyGqZTF5+HZZjuYyoRfJkoDsOe14Iw4Jlnj8ePhsUuUDLzSLfNlkChyIZkwjIWK6JqylI7LPW+7TtdJGYX74dle+SrqbCzHywio0CK8AgwO5P9VH6HfeK7XnEYAdB8NSEWByIcyZZKF8mrNG3ry6Azvf7lyiR0dkPSjSPRETKo4xyjEPBC3DTimULjnnG9BTSCqyowD46QcWuVa13KPm7KyfF5jJPZ7qsE4dLyweHzvs8o7rS/2r4aCJKaSg+jZ/XhYbx7aWxYjcs++CXNqsRmFHEfnlBWy7D6iAYd6CIriRaRjddwDQ+l245zUcTKmlgdB1eEvPGiXlNzCY4l2gbURo0IVWZXXupm/hpA+8B3sbnTw7PmgVlialBtXw2s4NA8P9QDY6NZbOTwPcu27gHOGt5yfD5K4bdOvqYVQ//XHpBJPdeOyryeqWLGqlSjWsKvkYhRc8kyo+6aJfjw/vDefCJCc3JV1Tev9iizv3+MJfOHaY33+m6pgQw45DrQJwydHATrChv374l9Vd68xATt0P4RX2cN6exdqZaIK2N+kN+5A+ZXYU3RZWZGqwvV3oTkKX2LLXQeblUjg+NhF1pacpluz/6FhZrLyK+Q2JparDX0qGxXGEPZV1RbPelEyXLPX+9FVixJyuDvbpzwN9E4vJrkgw573gKuyXr8NEGZFtxu1lNKKuPdlRuS3EcVvnomRMHeGP40Mmofpykl7llajDHakMusbux8/s+UWRoV1cbePsB8c3yNaCaQ6yY68lbdW3ysA/+ET64Rtqy7Lu8vlX2Eexkp3cNWTy2yljsrb7gp6mMR7Es3CtCjg6R/8pxq5XPKChSGUBwRjUDLIRu67uMo46fVlBfQf1f+PK3XYPQxot36CdR9j3PC g904+sVW iksUE2KoT6J1c1vZvXX8ERxIav2ivm+AxfpeUm36RAqt/Yq9ilLDQ7YmSniiiwP7/Cpd3FW+GHDUkdNSCV0Phr3AwwoPxO1v9+chqfUWATUf9oHNHPRZswcKqe8LC0QjneR76WcmQ64KkM+xbHayX6muDbksqYofOKgQMcHnpr15wGtqi/xK6zBeMUnZFv8sSW2S1Ez05NkBlkAa/SlAynpTpBdyXfqAAt/hJeHRz4mCadJ7J3nb1SKmfGyRR7iHo/wJyj4pUfRZMMLBr9ZuWjhkrvP0ouJYB4FDtdS9RKgbxra8MMF1MlLZqGd/Fa7KcDgOnu+JDqYyfNqIq+MW20qYkzDhqZt2qhpTdw5noSrUMu3LDEqPxIuvon/q7/pdnqS8n 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 Tue, Jun 03, 2025 at 10:57:21AM -0400, Peter Xu wrote: > On Tue, Jun 03, 2025 at 03:50:54PM +0200, Oscar Salvador wrote: > > On Mon, Jun 02, 2025 at 05:30:19PM -0400, Peter Xu wrote: > > > Right, and thanks for the git digging as usual. I would agree hugetlb is > > > more challenge than many other modules on git archaeology. :) > > > > > > Even if I mentioned the invalidate_lock, I don't think I thought deeper > > > than that. I just wished whenever possible we still move hugetlb code > > > closer to generic code, so if that's the goal we may still want to one day > > > have a closer look at whether hugetlb can also use invalidate_lock. Maybe > > > it isn't worthwhile at last: invalidate_lock is currently a rwsem, which > > > normally at least allows concurrent fault, but that's currently what isn't > > > allowed in hugetlb anyway.. > > > > > > If we start to remove finer grained locks that work will be even harder, > > > and removing folio lock in this case in fault path also brings hugetlbfs > > > even further from other file systems. That might be slightly against what > > > we used to wish to do, which is to make it closer to others. Meanwhile I'm > > > also not yet sure the benefit of not taking folio lock all across, e.g. I > > > don't expect perf would change at all even if lock is avoided. We may want > > > to think about that too when doing so. > > > > Ok, I have to confess I was not looking things from this perspective, > > but when doing so, yes, you are right, we should strive to find > > replacements wherever we can for not using hugetlb-specific code. > > > > I do not know about this case though, not sure what other options do we > > have when trying to shut concurrent faults while doing other operation. > > But it is something we should definitely look at. > > > > Wrt. to the lock. > > There were two locks, old_folio (taken in hugetlb_fault) and > > pagecache_folio one. > > There're actually three places this patch touched, the 3rd one is > hugetlb_no_page(), in which case I also think we should lock it, not only > because file folios normally does it (see do_fault(), for example), but > also that's exactly what James mentioned I believe on possible race of > !uptodate hugetlb folio being injected by UFFDIO_CONTINUE, along the lines: > > folio = alloc_hugetlb_folio(vma, vmf->address, false); > ... > folio_zero_user(folio, vmf->real_address); > __folio_mark_uptodate(folio); I think I was wrong here at least partly.. So what this patch changed is only the lookup of the no_page path, hence what I said here doesn't apply. This patch also mentioned in the commit message on why James's concern was ok - the fault mutex was held. Yes I agree. Actually even without fault mutex, the folio is only injected into page cache after mark uptodate.. so it looks fine even without the mutex. Though it's still true there're three paths to be discussed, which should include no_page, and it's still needed to be discussed when any of us like to remove folio lock even in the lookup path. For example, I'm not sure whether it's always thread safe to do folio_test_hwpoison() when without it, even with the fault mutex. Sorry for the confusion, Oscar. -- Peter Xu