From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9485C2EC0B5; Wed, 29 Oct 2025 15:19:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761751189; cv=none; b=bdExmnuSqgJE3LDhjJuSBt3U/AtIE2NYTxirveunrS8Gp3zhJ4sSWjLDAfIoHaxe8YoYBUbIyiuYu4BHwP0hFBjgh1N3tdckiO6t3Ld+rmbZ8ycDuSeiJZfHekcXWUkiKBChBFfPw8bOB7NBz9XmvKgbEvalsYiktygn7zGlJ6I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761751189; c=relaxed/simple; bh=qbQeMVbo3l/1GuPlXKkSxZu63+LRj3CaWonnsm1omOI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Sh+B06jMwwe2ciduXW85azqVDxJX1WFwypan9zkJXMgzkuKZnYcBPuxmoESe+bbFO589JDa9fOximm0tcwr6T0n7PUS4Sw+YSwkrZ7QGdlBLbMLk0Q5NQid5DanR/KOgYBXjanZ26iTelk/finVFe2p1bmBro1JJcdpdGdWk3fQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WGlaV1NL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WGlaV1NL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 27021C4CEF7; Wed, 29 Oct 2025 15:19:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1761751188; bh=qbQeMVbo3l/1GuPlXKkSxZu63+LRj3CaWonnsm1omOI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WGlaV1NLoi8Trlg7yWiQ4wTETMtoEv8SYUn51u6cYoJZDz1zsKrhloR22pgobKrtL gZme/C19Cq/w9BkaBXGaAhYFqPphMZEox3vaLKF/hKQGrj4C7ktY+hd8iTjBNJWQ8U ak4QYOswrIHVC7pytc+ndXaQFAEwMC1IZhPkQb4MlD6/yerKL8saSrBcz2K6QIBpG2 yd6Qxr0fqSIldgKyCk7PlcKquqckQ1AqLRnJDekHy8IDrnxAAcfXnqzaBg2yyt5KYa nw6r6bx6jLEVJYKq8PfrrYB31z6oaeIvZv3nHtF/Y+oQXsGMMwgyqBtBJSCMTSF85x CXeoVFZdWVrdA== Date: Wed, 29 Oct 2025 08:19:47 -0700 From: "Darrick J. Wong" To: Kiryl Shutsemau Cc: Hugh Dickins , Andrew Morton , David Hildenbrand , Matthew Wilcox , Alexander Viro , Christian Brauner , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Rik van Riel , Harry Yoo , Johannes Weiner , Shakeel Butt , Baolin Wang , Dave Chinner , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv2 2/2] mm/truncate: Unmap large folio on split failure Message-ID: <20251029151947.GM6174@frogsfrogsfrogs> References: <20251023093251.54146-1-kirill@shutemov.name> <20251023093251.54146-3-kirill@shutemov.name> <9c7ae4c5-cc63-f11f-c5b0-5d539df153e1@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Oct 29, 2025 at 10:21:53AM +0000, Kiryl Shutsemau wrote: > On Wed, Oct 29, 2025 at 02:12:48AM -0700, Hugh Dickins wrote: > > On Mon, 27 Oct 2025, Kiryl Shutsemau wrote: > > > On Mon, Oct 27, 2025 at 03:10:29AM -0700, Hugh Dickins wrote: > > ... > > > > > > > Aside from shmem/tmpfs, it does seem to me that this patch is > > > > doing more work than it needs to (but how many lines of source > > > > do we want to add to avoid doing work in the failed split case?): > > > > > > > > The intent is to enable SIGBUS beyond EOF: but the changes are > > > > being applied unnecessarily to hole-punch in addition to truncation. > > > > > > I am not sure much it should apply to hole-punch. Filesystem folks talk > > > about writing to a folio beyond round_up(i_size, PAGE_SIZE) being > > > problematic for correctness. I have no clue if the same applies to > > > writing to hole-punched parts of the folio. > > > > > > Dave, any comments? > > > > > > Hm. But if it is problematic it has be caught on fault. We don't do > > > this. It will be silently mapped. > > > > There are strict rules about what happens beyond i_size, hence this > > patch. But hole-punch has no persistent "i_size" to define it, and > > silently remapping in a fresh zeroed page is the correct behaviour. > > I missed that we seems to be issuing vm_ops->page_mkwrite() on remaping > the page, so it is not completely silent for filesystem and can do its > thing to re-allocate metadata (or whatever) after hole-punch. > > So, I see unmap on punch-hole being justified. Most hole punching implementations in filesystems will take i_rwsem and mmap_invalidate lock, flush the range to disk and unmap the pagecache for all the fsblocks around that range, and only then update the file space mappings. If the unmap fails because a PMD couldn't be split, then we'll just return that error to userspace and they can decide what to do when fallocate() fails. --D > -- > Kiryl Shutsemau / Kirill A. Shutemov >