From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794227183; b=NrIrE9yApcsqVd5SU3ZiyjqhfbZBh5i9xqCllwy+/hpyEwnCiS9SINaoa6Nt+fUm03/o fSO+N6hU2uCUpIlnNgaOXaadMOlPMsC0NbaZzZNjjDV8PC/xItR0ckRcVlGT9kxIFFixY VUf+T1NyZCkRZcPK7JdMhmUUFxBOjZVGNELacL30Wk8gmNM6dTX685/qV+C5OD9OmUqUb Ok1ugviyAv9D9QiIIn34Pw2u2P2+5TZYwomOD28zXQCQ4npqdbrc7HGXcX3E4SE0pfRZs a99t9hcKkDfF4UhcVQfzZVLN6+IvL511H/gq5aIBZiSzAsJ5tFBnycme0oiHzRvPguA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794227183; h=Received:DKIM-Signature:Date:From:To:Cc:Subject:Message-ID: References:MIME-Version:Content-Type:Content-Disposition: Content-Transfer-Encoding:In-Reply-To; bh=6+EKYQdPiDyWXkzzfV/UN8vBxInBjW4N6ZELhlBfhOI=; b=FravJIZPmJWItFVVMLMskbgWqU7crZr5vlViguxVfCH3UAh8W/8KcprpC5sqA27dNA6I XfQfEuYpWdg10AGdYVERwxyvnJTUiRbAtpxtRdMnRBKrQfCMFQsYR6la6ycqBr5L+cbF/ CCbl8pXhNakEck3IKSCctFEHMMlJCfRDWgGqSd0sTvU0F/UU1Gl9Q44SM7pZ2reCzL6G7 S5F3OJANODDPdlcak96qiA+K+bKGmxy7eqE0fMlif8fmo552dmgDtzyPPyyfH0yYLfS4h R3KWz87o4PQqkpirYcU3rc+cEthaL0341PymLTfKsM8Ova9CwXG1AeVGR9mIkY44iEQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=VhodTs+A; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E9811606A321; Mon, 9 Nov 2026 12:26:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=VhodTs+A Received: by smtp.kernel.org (Postfix) with ESMTPSA id 937971F0089F; Mon, 9 Nov 2026 12:26:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794227182; bh=6+EKYQdPiDyWXkzzfV/UN8vBxInBjW4N6ZELhlBfhOI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=VhodTs+AWpB6b78audXhz1hdToGnTfiqsIeh7C9iS51ypshI9FNnayYXFucaMgeLZ xeEIungcy0zjIPzwmpAqArp8eRXgn6aLR4nNmqHiWaRHWsbsQ7Qxh3+PgSaQmGodli iH97FzOVZfiuF5Da5WjkLmXe3XJknzf7SbtxrzdHDZZM2QKqqAHZOHOY4doionvKHw 4h930muPKhPQSSHI+AAJgxUYDe3aTAGC8NAItOXceOH2dwmRr1lJ1teB6f1iCQBu+D 7GUCaRQliXvLQza+jV5DiZhXeIr64nvzKuidlvAiLong4iDN+nDILPyMHrAS7gpG/t Sxhmv2E4eHoMw== Date: Mon, 9 Nov 2026 12:26:00 +0000 From: "Lorenzo Stoakes (ARM)" To: Barry Song Cc: sashiko-reviews@lists.linux.dev, Andrew Morton , David Hildenbrand , Jason Gunthorpe , John Hubbard , Peter Xu , "Matthew Wilcox (Oracle)" , Jan Kara , Rik van Riel , "Liam R. Howlett" , Vlastimil Babka , Harry Yoo , Jann Horn , Lance Yang , Zi Yan , Matthew Brost , Joshua Hahn , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Kiryl Shutsemau , Xu Xin , Chengming Zhou , Madhavan Srinivasan , Nicholas Piggin , Michael Ellerman , "Christophe Leroy (CS GROUP)" , "Ritesh Harjani (IBM)" , Shrikanth Hegde , Pedro Falcato , Kairui Song , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Baoquan He , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Leon Romanovsky , SJ Park , Rakie Kim , David Rientjes , Alexander Viro , Christian Brauner , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , Masami Hiramatsu , Oleg Nesterov , John Johansen , Georgia Garcia , Paul Moore , James Morris , "Serge E. Hallyn" , Mimi Zohar , Roberto Sassu , Dmitry Kasatkin , Eric Snowberg , Fan Wu , Stephen Smalley , Ondrej =?utf-8?B?TW9zbsOhxI1law==?= , linux-mm@kvack.org, kvm@vger.kernel.org, damon@lists.linux.dev, linux-trace-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, selinux@vger.kernel.org Subject: Re: [PATCH 02/13] mm/filemap: convert fault and readahead logic to use vma_flags_t Message-ID: References: <20261105-late-2026-vma-flags-v1-0-0d3cd15ab75f@kernel.org> <20261105-late-2026-vma-flags-v1-2-0d3cd15ab75f@kernel.org> X-Mailing-List: linux-trace-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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Sun, Nov 08, 2026 at 03:42:36PM +0800, Barry Song wrote: > On Sun, Nov 8, 2026 at 3:20 PM Barry Song wrote: > > > > On Fri, Nov 6, 2026 at 7:53 PM Lorenzo Stoakes (ARM) wrote: > > [...] > > > > -- > > > > Sashiko AI review · https://sashiko.dev/#/patchset/20261105-late-2026-vma-flags-v1-0-0d3cd15ab75f@kernel.org?part=2 > > > > > > It seems these are valid, oops! > > > > > > Andrew suggested a fix off-list, and I agreed to this as an in-place fixup to > > > avoid respin. > > > > > > I have also updated the series locally to reflect this change: > > > > Seems like a reasonable fix. maybe_unlock_mmap_for_io() > > could have released mmap_lock, leaving the VMA > > unprotected. but ra->size *= 2 is still going there no matter > > if the vma has disappeared > > > > For the original patch combined with the fix, > > > > Reviewed-by: Barry Song > > > > BTW, one question is whether mmap-based readahead is > still worthwhile if the VMA is actually gone after we > release mmap_lock (or the VMA lock). Perhaps we don't > need to continue readahead in that case. > > However, we don't have a reliable way to know whether > the VMA is really gone until the page fault is retried. > We release the lock to perform readahead, so in this > racy case, readahead might be happening for a VMA that > is being removed. > > I'm not challenging this patch, just leaving a note > to think about later :-) I suspect it's one of those 'not worth checking' situations, VMAs can come and go at will at any time and theoretically you can do useless work, as long as that's mostly not the case I think we're OK. And in general I think these code paths need significant rework before we revisit stuff like this, we always pay a tax for code complexity! -- Cheers, Lorenzo