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=1794082215; b=uHXW3fAvQtUp7AwtObeDMEY2z5xz2SuP20HBG6V+k8SvStKuexo39nTUdBe/7ZWaoWpI LD9qLi8kYqeizve7W5eR/GZIdZijURWkV1Ob8mRTQWduXYljpMX6dHWHjnPOrcFP14lF5 sMS7c4eOwLqe3dL8NCLdc7ZfdmCFyqSFP71FUYAp8aA+9QqSBKdEX50t1PyuL9qvdDuZX TsqrRA31M8HFahZ37v08GKHuC8LdcGNG51utO8/8/0CIlaoXLPPHUUCTTPDfOagwLcFRL YMJn2PhLqPOtBJIsOt8GGlTIsXWOc06fFrOzdapk+ebBgATmGs5qPG+qZ7FyzhikI1w== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794082215; h=Received:DKIM-Signature:Date:From:To:Cc:Subject:Message-ID: References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; bh=CMFxkbGnr/NpLAXZXk8rbwy5EGs+66IVJk9lKIVoNp8=; b=uX1djr4KrJAMZKxMVMBGYBEm/Gr7wt1qgnOzrDxZK9R1iSBgprGdLPyP6K/Kq5ISNBIN wMVrjJPxY+WYgwM6OzCuCxosnXy6wpI7W2HCMKsmd4geOY/3EXgMLxeQzoTZZKzIr/H56 N3barsESmMZbnsBeKFP/sE+lvJdpfnVBVYh6KtGrA6YPQCjDC5vbFEdrF/uGb8eu08gGQ IIiYpTSbihqegc9CVuAUJXC/ca/2FRym+yV5s/6JKpiCAr5bxDzblan4+s6Pnbta5N+DB y+rKReozhIyNO+exF3zibImrmrZ/WANB3SHiefsi5qtkY52sPd3I9px3QHhTq1zuMRg== 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=iLeOYJRj; 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 830D7606A331; Sat, 7 Nov 2026 20:10:15 +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=iLeOYJRj Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8D661F008A3; Sat, 7 Nov 2026 20:09:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794082215; bh=CMFxkbGnr/NpLAXZXk8rbwy5EGs+66IVJk9lKIVoNp8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=iLeOYJRjjnhZl3LWMSGaUd1S27vEBJh9NrDzelAqlZmg4R2RciRfWoeIsojODwzqH AmV3EGrrSvx70iXnLVmV7/bs2dBDE1x/r3nyPcxADmxBtch4xZP+oTaqLUfx+eYAuG SGRWdAxli2sYIZwe/Tbuw0udh+c0QNfiwmJOXLSfQKYp1etxVNRgoDq0IPlAd0lt9t yDMA0BPoIWju9BFMAW7mO+dutMm2GHuzj6pjWBP8PMNdT9kLO2lCpBJij+NhIf7LIF N/2SXcwPj4meyprPc8KlcX/gZ5yZ2cdhj422kyiEPIrnEjIKnHoNmFfhk++nuATcLn UZoP1hyr/4Jww== Date: Sat, 7 Nov 2026 20:09:55 +0000 From: "Lorenzo Stoakes (ARM)" To: "David Hildenbrand (Arm)" Cc: Andrew Morton , 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 , Barry Song , 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, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linuxppc-dev@lists.ozlabs.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, linux-integrity@vger.kernel.org, selinux@vger.kernel.org Subject: Re: [PATCH 00/13] mm: continue vma_flags_t conversion Message-ID: References: <20261105-late-2026-vma-flags-v1-0-0d3cd15ab75f@kernel.org> <1c0b1368-a381-4b25-bba9-7a4f8e92b764@kernel.org> X-Mailing-List: linux-perf-users@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: <1c0b1368-a381-4b25-bba9-7a4f8e92b764@kernel.org> I think we're slightly talking across purposes, so to be clear - I am totally fine with you taking any of this through your tree or whatever works for you and Andrew to avoid merge pain :) I was just talking more generally about how to merge series that touch a lot of subsystems and maintainers-who-may-never-reply, etc. These are the edge cases that make things... fun :) Anyway, I guess easiest resolution here is for you to take the bits that belong to your trees and Andrew takes the bits that belong elsewhere? I don't think anything here has an inter-dependency. On Sat, Nov 07, 2026 at 08:26:29PM +0100, David Hildenbrand (Arm) wrote: [ ... ] > > Because of [PATCH 05/13] mm: convert THP VMA flag tests to use vma_flags_t which > is THP-only, and feels like it could go straight through one of my trees, > avoiding conflicts with Andrew's tree. But maybe there is more to it that I am > missing. Sorry about that! Please take that through your tree. > > I assume stable topic branches would fix that, but they are currently > unfortunately not on the table ... :) I guess we need everybody-on-git for this! I guess when Liam and & I have the VMA tree we can do that at least for stuff that goes there :) > > > > >> > >> Ideally, patches really only touch one component. > > > > Right, but sometimes functions are declared in one place and called in > > others. It is impossible to change the signature of one without also touching > > the others. > > Yes. Something like that is unavoidable. Or if you need new APIs/ Yes. > > > > >> > >> [PATCH 07/13] mm/madvise: convert madvise_vma_behavior() to use vma_flags_t > >> > >> is all over the place :) > > > > It's not really all over the place, it's converting vm_flags_t to > > vma_flags_t across madvise.c, which involves changing a few function > > signatures, whose callers must be updated. > > Ah, yeah. What on earth does arch/powerpc/kvm/book3s_hv_uvmem.c do with madvise :( Yeah it's quite worrying that... :) > > > > > I could split it up into 3 patches where 1 does internal-only, one changes 1 > > function, and the next changes another, if that works? > > No, these things really have to go in as one unit, no need to split that up. Thanks, yeah, it's a pain I know but eventually 'one fine day' (probably in 2028) everything will be converted to vma_flags_t/mmap_prepare and we won't have to think about this :P -- Cheers, Lorenzo