From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=95.215.58.11 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793918645; b=3Fo7ZLVpJnRlAVoUCSsjP0zulDiNjLgyhgT9ahqGRfHtlO19eLtFnascqFZXzu+wR88i bDhfdO+kjLyo1XAIKxXMeXtAQFy3bnek2rPoPJ9mAhCe0IuCAWaMdBO4jcs3D+fzjiVsf icrMeCmEl3kZTVlCGlEIFtmVzNPjKp0mDoEhMRCQEpumXL/2Vlan1AdU2w7+5v/HUTrZC ZkAo0uiGhGyk8gpC37oID+d++ClJ5vIKFqmlh+W8wEOpj4/jlj2ibR+GkMtPQLzlQsDYH itKAC9TIpFRdQcAre8G/t6foECjljK9oZFncRPccd5FQlg1wckqIhGM1usR8FBOS+ig== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793918645; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:Date:From:To:Cc:Subject:Message-ID: References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; bh=JxLJNgnKaaDtogy9UDJ+u4IBfGkMCrx4gqopdXLbwqE=; b=3si2gVdfBOnaBJGnguSHPU84LnByWLMzuFA7val0M/lmPWnNCoIq6oAP8grXhggRARdg FThNJHJaZHqrVtVL+rN/ZLkwmIXuG/Li/ZhRFuAiygDNx3c1kOvL1vJc1AeC8dvJhEdGF O45oszHDXGGoawBfssH3c8r6VSrk5w5UXCEOgNPwa6m7h4Bw1kqft/b18Y7JPDut6Vevu Ouh29VX3S3peOr/XCY51fgAMkBezobFTD2fwl16JYb9ApRiT0a/qLtC49GWKfv2JRmV+U Cf9O4QyZxMf2yC3ZIVO+9rbxpFNE/CKVwPI0B4+M/p//2hKqJi209nhlVc9+9nv5F/A== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=rp7glFqH; arc=none smtp.remote-ip=95.215.58.11 Received: from mta1.migadu.com (out-11.mta1.migadu.com [95.215.58.11]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7DA6C606D816 for ; Thu, 5 Nov 2026 22:44:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 7DA6C606D816 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=rp7glFqH X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=vAPWWkIFDwbgy2wHFM/rAmP8el8Mj7wGKfgTaZhtpZ4=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1793918642; v=1; x=1794523442; b=rp7glFqHvrLHbMfBSaPiYJG22IM71k3aN2mJXgKV8YPS9ZSnI0eD4CGSpjLSYsqaCbG5rVU7 niGJGtmUA431/BKVodx+m/HkN3vVu/yDMxehWTLamDYafgLyUpZ6bt5suRnNrAgPbvce5imoIzY 5T3SqgXEZUkCHeEd5Y8xay/Q= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 960618cb128bac7d; Thu, 05 Nov 2026 22:44:02 +0000 X-Mizu-Trace-ID: 960618cb128bac7d X-Migadu-Flow: FLOW_OUT Date: Thu, 5 Nov 2026 22:43:58 +0000 From: "Jose Fernandez (Anthropic)" To: Pedro Falcato Cc: "Matthew Wilcox (Oracle)" , Jan Kara , Andrew Morton , David Hildenbrand , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Krystian Kaniewski , stable@vger.kernel.org Subject: Re: [PATCH v2] mm/filemap: stop fault-around when the walk steps back Message-ID: References: <20261031-jf-mm-filemap-map-pages-lower-bound-v2-1-21029744e589@linux.dev> <20261104-jf-filemap-v2-pedro-reply-r2-74c87c6fbcf@linux.dev> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, 5 Nov 2026 12:19:13 +0000, Pedro Falcato wrote: > Thank you. So, if I'm not mistaken, this is the race: > First, you map/see this: > [folio pgoff 4, length 4] > Then, at some point in time, someone punches the hole: > [no folios here] > Then, at some point in time, someone faults another folio in the range: > [folio pgoff 0, length 8] > so you step backwards. Is this correct? Or am I misunderstanding this? Not quite. In my test a large folio goes away and a small one comes back below where the walk started. If that happens during the walk's first lookup, the walk can step back. Krystian's fix doesn't cover that lookup. In your order it doesn't step back. The new folio covers the place where the walk is, so the walk either gets it at the right index or skips its sibling slots. > If so, how can this happen while we hold the PTE lock? That itself should > block truncation. We don't hold it yet. filemap_map_pages() does the first lookup under RCU and takes the PTE lock after it. > Can you share the reproducer? With the delays it can corrupt memory on a kernel without this patch, so I'd rather not post it. I can share it off-list with the maintainers if they want it. The 40 runs without a delay were on a debug kernel with the delays set to 0. Andrew, I can send a v3 with this case in the commit message if you want it. - Jose