From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AABBE156236 for ; Thu, 29 Jan 2026 21:30:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.160.170 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769722246; cv=pass; b=IWu6wnQlujPxMonx3OAyQRnGE1rQN9dw0ozVtjYyDpTKOpYeBAtp2nQrLIabmM3xDI2LhlZokWmuROTnliwyQMsUWwHmdts4IEr2ijParQEfzuGODtY2gkNZeVdwhHRTvWLUMn2Me8N5JrKpG8RFWn3Ht6w+d2Ybm8FC+NntU7w= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769722246; c=relaxed/simple; bh=rqLjDpUUNSiY+YyjTPDjCda4G1BOQx/wSvWpnCAssLs=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Gi4mT2BaPtbZ5vLBkZr2aVMqFAZ0kNmDuHWBYBCG++obh6W90OBi1TXOuj+UDG4AHzziaLyntCYdk2ZyDXfoa1qQNHmAKMKm/QVKNGLbbBDtf2PeJSPo6/wOF5XHvinoA25yoIK7I9nO8DEHn6Avuq7Z9KVS0SUMC+rJGf1m3tU= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=2uHosfXd; arc=pass smtp.client-ip=209.85.160.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="2uHosfXd" Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-50299648ae9so11221cf.1 for ; Thu, 29 Jan 2026 13:30:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769722244; cv=none; d=google.com; s=arc-20240605; b=XlgpeNf2vOpasRI4mmzmNFb2qIBoVIho3h4VpApQ2ZRv0ofLRBbny/vum8AIp5StnO cvI3hGbn2BwmZgoIJstB4SWiOlhjc5ojDFqPB7078CbxSDS8grmGs966ftHnWD6mOmnB TZrSLqm56M/QQYJHWMvv4B4vePfUee3qUD89NQXgCujKwFrSubXpz5qXWGLwZh55Q0Ek ZzgE+xZbI9wGW0RnuF/v6Pq1cmsb44ujFzF4ahQX6zGRXXcCweW71+GsDJzfO0OuKQEb iww1cLXUewBLdcehl7gWJFlHRVzBHZ87hVuqk2pk061U9AZ8c/5YqwGlDScihHCFvKtc 9R0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=JqxcN7KtTUu9rL1wIU9EI9qT3i6tnGntzVMiIiyYLMQ=; fh=ijwMIe/7/ytKiqZf0B5I3rqoJ9DGvRkZ7EXPi72BZao=; b=lymfcnoI/IpfeN3kMs55aN2NAKwDPGcgbnaUOTwLgYxPMWUXI8tb6gNTzVLm//Ok3n wXBP57JCXYT5dVf4shxT+xnzqTQMcfxg9hRFzG/vqp+1ktGlwCY9wUV5lJlDJTjEWMg0 QkU1Mlm0+JOIdXWwkoz2wI0i0NtcDITr1TjJa2if/qTNXbWjUIvbrM/Mn4SmenpwjHxG vm9AjFCwKeMOr4hrR2KG0DmC4kg4kp4QOeA6tCwYTrwRVHKTDSTLgkttP8JEX0rz3VG5 0b573/kC8M0qinHH2uk/IikjrrRGGQ3p6FPjEDR0IUcfd4ZAkNjt2YZRHqN8Q5WCMRsZ dlmg==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1769722243; x=1770327043; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JqxcN7KtTUu9rL1wIU9EI9qT3i6tnGntzVMiIiyYLMQ=; b=2uHosfXdLjZywX0naMiqULcnNwP1IfQXJELLm5wcufDh24g4uWku/1vlK1ILsFT0vo h01fZ2DqU71/TEMtcugQBFMLxCN7bxnBdImKYM3zT5KY+sEcWLqh4O+vDqZa5uvLeNw+ ACOcMGbdmQjhx+QJ5XZFy3ZVH1GRGbnmd078L9ljWB21e8n3y7Qo9x2z4pszKMn8W1e5 hW4p1MZa1lSrSqngovJqIi/LHJhzx0Eb0Bx4JQluHO4TopNXS6nTfcV+fieWnKIsC/g6 Yb71Ysg2FIZuFCO5rqBxVzr5dXfBxTvJSQIdhLG1DIr+vQRFYYjMj+FPh85FZ2d0HR57 s8ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769722243; x=1770327043; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=JqxcN7KtTUu9rL1wIU9EI9qT3i6tnGntzVMiIiyYLMQ=; b=p+2ddKjXUEcctb/FbN6+L/HZU4mT1XlyDfgyAwoX8VupHYBmCVoKK18iGH/hfg2p5l pLV/QJRNDygZYw/POPXLVp7mvM0U29k3s1jPXIxajaMNX2lStIj01JkIkFVDjWx/5wRd GdWrC0ruIlaOl9JD0LFo6SanMJmTMzzoh5WeFED9ZHmenD9U7MzifQNlnnxat+TBixJQ fIbf5F0W0AsCUDzUnZOd9uGidzme1jqOrn0yx1czeSksmYfqrSqKB5tQ8lt+yhfkRNU2 gfYAya4og1oEaCqbMaYCXqc0dsX+ebnQpLm79+b/mLWA474idDSD8m0F0YaNYuyHvXSX VGbQ== X-Forwarded-Encrypted: i=1; AJvYcCVNBnwQ41ca6o8GuLtByZFuUIzYo7f2aAuUeQPxm7NNQ4VcwBtphaq8O7vgd9kVH1X+f8xT5v5G/075P9U=@vger.kernel.org X-Gm-Message-State: AOJu0Yx6CiS1crIKQt8kHkuY8q/LI8ET9Oxgoi5e8lum+zPwHwPAJQAU 4Fl+2jCpt0s738Ll15eu3vsuWwjNe0eexAfP6mRS2qgabQdL9zDIPSH1C4WZ5v/75yPAFUlYHMk ClatAY/Pek83H3lx+fQDBUyfMefki5ozbo4hcIB0S X-Gm-Gg: AZuq6aLQpRNVib8FrVi83efOwvdDZoNNi2WRd5apghFLHvhD2GawEfWoTaJ0cLPK8A8 NIHwONrMUl+k1L/wKOVVUWj6d149m+TtApeWPvyKtkVWylDzu5TTBw8o6gae0yNxqi6ewcETLJg LTEm62IkGEgHV2sH1c/yjldlQe9o35r6svOEeukE13yWfo9xEez6SrU5eWqeR1VUwCMTEHVWboV M1I3MSwloK3kE36Py83VFBvs4JLeR7O8AjvYbXzKjRydeuhdedsRdIzHB/aphk5QugaAHA7kdbp CSi2sqBokW/uUfDt1rWSAfU6Yw== X-Received: by 2002:a05:622a:1a85:b0:501:197d:32af with SMTP id d75a77b69052e-505d282fe19mr1768141cf.0.1769722242948; Thu, 29 Jan 2026 13:30:42 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260128113749.osNjwNqo@linutronix.de> <71c45f74-0fb5-4ec8-aa67-d700df94b617@lucifer.local> In-Reply-To: <71c45f74-0fb5-4ec8-aa67-d700df94b617@lucifer.local> From: Suren Baghdasaryan Date: Thu, 29 Jan 2026 13:30:32 -0800 X-Gm-Features: AZwV_Qgm5gepZ8gbgQe6dEjUltBBWBnJtHfDRyEYqgKQxgjXh9yeS3JPa-VkvQk Message-ID: Subject: Re: [PATCH v4 04/10] mm/vma: add+use vma lockdep acquire/release defines To: Lorenzo Stoakes Cc: Sebastian Andrzej Siewior , Andrew Morton , David Hildenbrand , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Michal Hocko , Shakeel Butt , Jann Horn , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev, Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , Waiman Long , Clark Williams , Steven Rostedt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 28, 2026 at 3:48=E2=80=AFAM Lorenzo Stoakes wrote: > > On Wed, Jan 28, 2026 at 12:37:49PM +0100, Sebastian Andrzej Siewior wrote= : > > On 2026-01-23 20:12:14 [+0000], Lorenzo Stoakes wrote: > > > --- a/include/linux/mmap_lock.h > > > +++ b/include/linux/mmap_lock.h > > > @@ -78,6 +78,37 @@ static inline void mmap_assert_write_locked(const = struct mm_struct *mm) > > =E2=80=A6 > > > +/* Only meaningful if CONFIG_LOCK_STAT is defined. */ > > > +#define __vma_lockdep_stat_mark_acquired(vma) \ > > > + lock_acquired(&vma->vmlock_dep_map, _RET_IP_) > > > + > > > > After going through the remaining series, I don't think I found a > > matching lock_contended(). So perf/ tracing just give you a few > > lock-acquired events. Wouldn't it make sense to also some > > lock_contended() events where the caller had to wait before it could > > acquire the lock? > > Yeah I did wonder about this actually. The series really just abstracts t= his > part, so I think doing something with that should be a follow-up. > > Suren - what was your intent with this? I did wonder what we actually rea= lly > accomplished with this. > > VMA locks are always try-locks. > > Write locks can't be contended against one another since VMAs are always = a > per-process entity and not obtained remotely, so either a VMA is write-lo= cked by > us or not write-locked, never write-locked by anybody else. Correct, all paths which call __vma_enter_locked() to either write-lock a vma or to detach it have to already hold the mmap write lock on vma->vm_mm. So, lock_contended() will never be triggered for vma write locking paths. > > Read locks immediately give up if the VMA is write locked. > > Would we want to record a lock_contended() event in that case I guess the= n? Yes, we could have it in vma_start_read_locked_nested() if refcount increment fails and if the refcount !=3D 0 (if it's 0 then the vma is detached and the refcount can't change concurrently). > > I don't think we'd want to do that if the VMA were detached, only if it w= ere > write-locked? Yes, that's why we would need an additional check for 0 in there. I can add this logic after your patchset lands. I don't think we need to block it for this. Thanks, Suren. > > > > > Sebastian > > Cheers, Lorenzo