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 536FEC369C2 for ; Sun, 4 May 2025 01:29:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 058396B0085; Sat, 3 May 2025 21:29:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F21516B0089; Sat, 3 May 2025 21:29:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DC30E6B008A; Sat, 3 May 2025 21:29:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id BA7B26B0085 for ; Sat, 3 May 2025 21:29:00 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 471EA121376 for ; Sun, 4 May 2025 01:29:02 +0000 (UTC) X-FDA: 83403491724.05.0D7943E Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf11.hostedemail.com (Postfix) with ESMTP id 8A46740002 for ; Sun, 4 May 2025 01:29:00 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=ewOq8mW8; dmarc=none; spf=pass (imf11.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746322140; a=rsa-sha256; cv=none; b=emFruQMFH92nbVxfZez50ZMi0TihrTocMQ96cfaG3RC5LOu+IMODErldyAYnbBzgsmKIdR 9Wkl4EcsZuTnb03xFiYCKlv5u0tWjq9CWUKM5bns25jmERK7ntm+EWwfHeGYdkUAamnVaJ ujYh5E6h7/0TWtExej5ROkZuggHKqbA= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=ewOq8mW8; dmarc=none; spf=pass (imf11.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746322140; 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=efWRQl9HOjzKegU+3Q32Dj51TdOtCn2X7AaoLipEbqw=; b=yI5W9MTj6E3SuINYr932Xx8706SpM7xekYZKEKTKtMVZTtZC+AsJoqUzjWiczY/F6tz5U9 NYW3sI6YzwZPgVR28EQaisr8d8LnmraTW0qGUQEsAeI8pemZGuxuRMAXmSfqDBmHQa0sak 2lTgeuAyyD6+u+oW+zH8fWIVAN0vszk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 1B242A40294; Sun, 4 May 2025 01:23:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BDA00C4CEE3; Sun, 4 May 2025 01:28:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1746322139; bh=7n/RkZelCee7HZb0JLnBTglCg0DQoVwRlQDp8IWWaHQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ewOq8mW8UDxL9+9ECv8Qfuakg+agxPoz8hWNSJQFDuvfrugw0npvbJUQxMy9Ahtg+ JM0F3+pCCGGpUGYUttE8oLGguaoQalZDqWc1OPU4/Xo3x4IPlVww/z628p+JTtuzL0 tuggwHoPh9Wt9A8kV+dO1nYp+gzyXcg1Mw2jHHRc= Date: Sat, 3 May 2025 18:28:58 -0700 From: Andrew Morton To: Petr =?UTF-8?B?VmFuxJtr?= Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, David Hildenbrand , Ryan Roberts , xen-devel@lists.xenproject.org, x86@kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2 1/1] mm: fix folio_pte_batch() on XEN PV Message-Id: <20250503182858.5a02729fcffd6d4723afcfc2@linux-foundation.org> In-Reply-To: <20250502215019.822-2-arkamar@atlas.cz> References: <20250502215019.822-1-arkamar@atlas.cz> <20250502215019.822-2-arkamar@atlas.cz> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 8A46740002 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: fgg76y549o1151w5w4q854nnffkuf54p X-HE-Tag: 1746322140-258140 X-HE-Meta: U2FsdGVkX1/A+EDAvdrvIvGv0lhqop64SCcvQYMn8yZqKpG3tOKpNrv9COo1CTiNQVOVUYoaxI8PqBCoGN2csJyLue6SbCG/2ydV+kCZ7iqlb/0BFfRoW5pJkrS/7IWS/VfJGwG6vE49KyN6HFZylxwawOj5Akj/WH5p+dxiIRiq3Q374eW9g68GKwDyhy56psWS7FvhoHl6OKjTZFolWrksJVS4reTxlD9u2HHXwPnaxnBt74AJkD41YCCp9c0HQVGtIEU+C5p+IaDSavS7y/YKnyy+Eupj6VXd6auz4dSOPj8f+cIPspuUlJryzwjD/vKafL53EKpmuQ2lZQTdEEAJ5+TS8zteCTtAX3YNC8g7B5nr4oYbUw8LINzryUHf+aS3xoj1LDKRIBY7hbWN0BRB9y7pjZukLweGPh9q+QGJ2TrAthJLewfFUfacVogZF27yixyqKd19bYadCURZ3AOiWGqUJa2mh+rDyidHY8/vWlDbNEBInlGRm4f4BXBJ3krhVNtsM+GyhVTFFuqf+qRVmYMXZb3TkHgd6y6B+V01AIutJ+XcWSlE65k5EN3m/0uMwjRpvbQ5wWR3ndnJ5xFAW6snIVmSGPblR0X5m2fkEAoIQ7c5DhP2pkkmM102WfGsTVIGQwc8XNlGG0v+bxKATuWY4Jtythan2Qrb5eacUGKHi5klknnKRWseDeJ7XpgdCC3AqpyrG5vekhOBvJbW3L7400nCeYcO6spV6JoSVpV/rKJ2zlqKHD2i8Kv73lb1+/WvoxOKtwHcgrGXJ6erQimO+J9aXj3vNrPuPGZoiR3fcgG+YV85xHKaYkmYan08Zgw4aENtAhwNw9WhfCk7hsHghbKG67DPOJ4z7EkfJWUYuBjQXgr9g8sr+KD2Ly7ND1MK3pkWZyNahB/RjSMuY9dFr4f7GDAjxICK/MBNGUoD60eD5AKvwpWcNNFH0uZrYg8gf9BO/msaZCF AzN422st VncsqYFk5UUyT4oU+YtPkcnRUZMB50LEwqQcTLrho21Hi+0Dml0xNbeYvOHIYrY+a+SnOlY6P/l6m8ZeV8nhkg2Jrvc8jybgHSDEUSt9RB6Hds7l4F+s5+QhjkgiUsO8Su+N5mdaY4bO5K5Zn9WiLHKzsYHNpfOsl0m0r/mQo4vvFJi3p6npjpay6Aow2NrxDj8zQp8S7N06EjOknuLzhbC9oQQsFEuDGn6j0Fkf9dsVVYWsf5nUDQPmzMkB36k9d6qC4JBP1CZEp1TlXNL0GVcl/QXZQ3oVQEOxVinUYlXuYVSC8L+lKJzDjmtT2k/wJAYt+ 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 Fri, 2 May 2025 23:50:19 +0200 Petr Vaněk wrote: > On XEN PV, folio_pte_batch() can incorrectly batch beyond the end of a > folio due to a corner case in pte_advance_pfn(). Specifically, when the > PFN following the folio maps to an invalidated MFN, > > expected_pte = pte_advance_pfn(expected_pte, nr); > > produces a pte_none(). If the actual next PTE in memory is also > pte_none(), the pte_same() succeeds, > > if (!pte_same(pte, expected_pte)) > break; > > the loop is not broken, and batching continues into unrelated memory. > > ... Looks OK for now I guess but it looks like we should pay some attention to what types we're using. > --- a/mm/internal.h > +++ b/mm/internal.h > @@ -248,11 +248,9 @@ static inline int folio_pte_batch(struct folio *folio, unsigned long addr, > pte_t *start_ptep, pte_t pte, int max_nr, fpb_t flags, > bool *any_writable, bool *any_young, bool *any_dirty) > { > - unsigned long folio_end_pfn = folio_pfn(folio) + folio_nr_pages(folio); > - const pte_t *end_ptep = start_ptep + max_nr; > pte_t expected_pte, *ptep; > bool writable, young, dirty; > - int nr; > + int nr, cur_nr; > > if (any_writable) > *any_writable = false; > @@ -265,11 +263,15 @@ static inline int folio_pte_batch(struct folio *folio, unsigned long addr, > VM_WARN_ON_FOLIO(!folio_test_large(folio) || max_nr < 1, folio); > VM_WARN_ON_FOLIO(page_folio(pfn_to_page(pte_pfn(pte))) != folio, folio); > > + /* Limit max_nr to the actual remaining PFNs in the folio we could batch. */ > + max_nr = min_t(unsigned long, max_nr, > + folio_pfn(folio) + folio_nr_pages(folio) - pte_pfn(pte)); > + Methinks max_nr really wants to be unsigned long. That will permit the cleanup of quite a bit of truncation, extension, signedness conversion and general type chaos in folio_pte_batch()'s various callers. And... Why does folio_nr_pages() return a signed quantity? It's a count. And why the heck is folio_pte_batch() inlined? It's larger then my first hard disk and it has five callsites!