From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 4EA023CC7EC; Sat, 11 Jul 2026 17:10:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783789803; cv=none; b=g4Xxnyw85iK6yDbMMhUQPS0Ld4UPlGyLnJS4eaPCaSnZPebw7ttW9p89wvtN9M3XbKabdLJYmc85ARxVt2kuF28FtV8qlAp5K0d4df47mzKqZezUk/3u9lWVLmNcd4d5p5K8wWLfZVEgULWZUQXhCc+rZK4g0hkR/U27+QiPd1g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783789803; c=relaxed/simple; bh=AvtNjMXUVGcPIUxCxCfqbdEtpU8jR9HOTGYaAlW6IJ8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UcC/7s/B3n6isEuRUwy61GKQevJNu9IjeNMJCZVa93vYCm+UtO1629fkAl+ugPlLEl7l82fRx0nuXHyMCVBVVVmh0/zmNlm3pJTHctpbk0bjDQRapYSsRM30ZsxODxSkt0aEdU+5KV6nWeWbxVatiP2LZJNRCUJ1IJiCs09q/vQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=k3fNhKS6; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="k3fNhKS6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA6F71F000E9; Sat, 11 Jul 2026 17:09:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783789801; bh=AvtNjMXUVGcPIUxCxCfqbdEtpU8jR9HOTGYaAlW6IJ8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=k3fNhKS66r/p/o8Bc1xI7ewhTioGM5eE5UxTbAfHwiEEG5NZOQoHjazK2cWX+6/SE v+U9r2rkD4VP0CNSplf/nSgPr33pdrLmGKOrJy6x0c8Xsnfudte+l8CuZRkvsJHzhL 2xzdkO2v+Q+2PPXWrMuMSvbGqEw9CmT9+ZHMiG1WT8jUC5NdwLiZsm50xu5zeD+/aW zvImcxhwsTnEPAUhEbcG4TpZeBj1kqZVb6dm8VWTrMRJu36W2lybHuDy0lpFg0MMPF ANsT8GKLEgijBVcxkcvqBp+1nPOUHmAwPtV+5/DPz8eLqjTPOJ42AuY6RZqVPq55n+ bc2Qco/fVIOQQ== Date: Sat, 11 Jul 2026 18:09:35 +0100 From: Lorenzo Stoakes To: Zi Yan Cc: Lance Yang , akpm@linux-foundation.org, tsbogend@alpha.franken.de, maddy@linux.ibm.com, mpe@ellerman.id.au, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch, l.stach@pengutronix.de, inki.dae@samsung.com, sw0312.kim@samsung.com, kyungmin.park@samsung.com, krzk@kernel.org, peter.griffin@linaro.org, jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com, tursulin@ursulin.net, robin.clark@oss.qualcomm.com, lumag@kernel.org, lyude@redhat.com, dakr@kernel.org, tomi.valkeinen@ideasonboard.com, hjc@rock-chips.com, heiko@sntech.de, andy.yan@rock-chips.com, thierry.reding@kernel.org, mperttunen@nvidia.com, jonathanh@nvidia.com, kraxel@redhat.com, dmitry.osipenko@collabora.com, zack.rusin@broadcom.com, matthew.brost@intel.com, thomas.hellstrom@linux.intel.com, oleksandr_andrushchenko@epam.com, deller@gmx.de, bcrl@kvack.org, viro@zeniv.linux.org.uk, brauner@kernel.org, muchun.song@linux.dev, osalvador@suse.de, david@kernel.org, baolin.wang@linux.alibaba.com, liam@infradead.org, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, hughd@google.com, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, jannh@google.com, pfalcato@suse.de, kees@kernel.org, perex@perex.cz, tiwai@suse.com, linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, dri-devel@lists.freedesktop.org, etnaviv@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org, virtualization@lists.linux.dev, intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org, linux-fbdev@vger.kernel.org, linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-sound@vger.kernel.org Subject: Re: [PATCH 13/13] mm/mremap: convert mremap code to use vma_flags_t Message-ID: References: <380f761d35a3faa4370f8b3f92e3d4af3d4c7110.1782760670.git.ljs@kernel.org> <20260702134947.25189-1-lance.yang@linux.dev> Precedence: bulk X-Mailing-List: linux-sound@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, Jul 08, 2026 at 10:28:00PM -0400, Zi Yan wrote: > On Thu Jul 2, 2026 at 12:07 PM EDT, Lorenzo Stoakes wrote: > > On Thu, Jul 02, 2026 at 09:49:47PM +0800, Lance Yang wrote: > >> > >> On Mon, Jun 29, 2026 at 08:25:36PM +0100, Lorenzo Stoakes wrote: > >> >Replace use of the legacy vm_flags_t flags with vma_flags_t values > >> >throughout the mremap logic. > >> > > >> >Additionally update comments to reflect the changes to be consistent. > >> > > >> >No functional change intended. > >> > > >> >Signed-off-by: Lorenzo Stoakes > >> >--- > >> > >> The vm_flags_set() cases below spell out vma_start_write(), but the > >> vm_flags_clear() cases don't? > > > > Yep as I said elsewhere, implicitly taking the lock is terrible and me doing > > this is completely on purpose to get rid of that :) > > > > But I haven't been clear enough clearly, so I should put the argument as to why > > that's ok in the commit message. > > > > Will do so on respin. > > How about also add a comment to vma_clear*() telling us a lock is not > needed and why like you explained a lock is needed for vma_set*()? > This asymmetry could confuse people. Well you do absolutely have to hold the lock once the VMA is initialised when using any VMA flags API that manipulates flags (apart from the explicitly atomic case). The argument here is that the VMA was _already locked_ at the point of clearing :) > > This patch looks good to me. > > Reviewed-by: Zi Yan Thanks! > > -- > Best Regards, > Yan, Zi > Cheers, Lorenzo