From nobody Sun Feb 8 16:31:57 2026 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (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 2A9CB156960 for ; Sat, 11 Jan 2025 04:26:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736569589; cv=none; b=qpNdSaWBfvFHjioVUiPM426B0Y9Dxu3+RNSzk7Ep/1IJ0lJsdAYBUKbCJu49msPMWlD5wYjHvxg80uQo+pGN7OQAbxgG9lm56HRy4uuqgBjZctozlZGvHekSJyGC/I7uqH+bJcnc6AjgxQsLwNlJczKvyECAQainQNcX5PrFMFQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736569589; c=relaxed/simple; bh=eQsx0wmiGJe2BPbUDGY56ZA9e41HJdyZq2H2i9aUEHc=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=IvTdmPj+edWxC9lMSP7TiD1dcl4/pHLHWYjdhJnrcHTzTPoZurxZISEl5KTNf6hBWQomreVSMgRMuLp7lOa5x62Le5brpfZigfmInICKog3SaWgDnYnOl/ClVTFjop+W+fQZxi9le30AqjpVLM/zb3O46PJQam3KkjVtQdSIiEM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--surenb.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=0fkdha4o; arc=none smtp.client-ip=209.85.214.202 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=flex--surenb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="0fkdha4o" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-216405eea1fso50027545ad.0 for ; Fri, 10 Jan 2025 20:26:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736569587; x=1737174387; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=STfGBHDxpr+nljSTXZBRe7awpLRa2H0ex1QXNY89OAU=; b=0fkdha4ooLEZdL2cx+3mi+R+ImG0GzjT4b6hoC6qR/Y8loJFg8Ajqji7QGUSoinbGz DJPobaNCjUSd644wsH4bROv204ucTpO8nI9vfUPefjCGV8Yejj589JQE9L7iHqT/0kVy 6aIdBuvtmPsY35baYHAGWiIG2nmZzCvp29kQhA4Azz/ywR9gRNiXKlVs+zIrdJy/AXSt H3GONMEMlnGstwPnJGdIdJZ7u57a0515Ax6VqhABWZ84QQVKQiMYjmDsM9drGnPRbfwF a2tX4tarp4cbznUio2QW63FEbUlqt6qQqYi56QfJMJLXaT+fqPXM6JE2z+zVRqz1rLUr RuMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736569587; x=1737174387; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=STfGBHDxpr+nljSTXZBRe7awpLRa2H0ex1QXNY89OAU=; b=I1jVXmNClVYyIzKSvqgBYVypN2qh/eVYnspSLR03Ez+W1VBTwt+9cnFlYQ3wVhqk6i MctQ+aBnnIvhhhjhXEmY5I2+9KUWtzqzPqKZZr0R9OLTMCe9HhwCph6Yb2qnlKymd/LC iKtAOpfFB6NOPTxjLzsQTNr9rLttPMm0I/LJAF2izP5nh0zonVabHpZ21VEoqk22D5ci lH/SdC76nIb4dshmBKvngrhyZzgNwfAGAAr7M2oVYT72bL92km9poOTzPbCxpgq/ZXpQ I5lYr5xveQgO7ICie9ABnrkG1TAN3IbYiwlcalA4bntRGwKavGkMK2MQpY0x11RFKjQ3 B23g== X-Forwarded-Encrypted: i=1; AJvYcCV5xV6cJoWPYbq2MzbA18ZMMwVOWQPaw9TQkz1iLLyzkC3jtXctaGTLsJm3mMfH4rQK/N19cLZdNShSB+I=@vger.kernel.org X-Gm-Message-State: AOJu0YyPGl7YSpsaEli+ftgMQ6poVm6DWEkHXlDVWY/NUzvqM2djq0Kj 5/9OpzHlQl0DtNHGlfqPXHj5sZfKlT0yO1hZPvAR4kdDwAcPC4COT4j7Y6tb7vtx5WQzNmA/hSj Wcg== X-Google-Smtp-Source: AGHT+IHvoBVJY80+e+qdsj3aPRMB2UfI+za8DGuxRrXd9nOwFJGkON2pj+F8zNabSAnJMgvKZtfO1mpbjyw= X-Received: from pfbkp5.prod.google.com ([2002:a05:6a00:4645:b0:725:e6a0:55ea]) (user=surenb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1489:b0:728:eb32:356c with SMTP id d2e1a72fcca58-72d21f459dbmr17649276b3a.11.1736569587302; Fri, 10 Jan 2025 20:26:27 -0800 (PST) Date: Fri, 10 Jan 2025 20:25:56 -0800 In-Reply-To: <20250111042604.3230628-1-surenb@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250111042604.3230628-1-surenb@google.com> X-Mailer: git-send-email 2.47.1.613.gc27f4b7a9f-goog Message-ID: <20250111042604.3230628-10-surenb@google.com> Subject: [PATCH v9 09/17] mm: uninline the main body of vma_start_write() From: Suren Baghdasaryan To: akpm@linux-foundation.org Cc: peterz@infradead.org, willy@infradead.org, liam.howlett@oracle.com, lorenzo.stoakes@oracle.com, david.laight.linux@gmail.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mjguzik@gmail.com, oliver.sang@intel.com, mgorman@techsingularity.net, david@redhat.com, peterx@redhat.com, oleg@redhat.com, dave@stgolabs.net, paulmck@kernel.org, brauner@kernel.org, dhowells@redhat.com, hdanton@sina.com, hughd@google.com, lokeshgidra@google.com, minchan@google.com, jannh@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, klarasmodin@gmail.com, richard.weiyang@gmail.com, corbet@lwn.net, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com, surenb@google.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" vma_start_write() is used in many places and will grow in size very soon. It is not used in performance critical paths and uninlining it should limit the future code size growth. No functional changes. Signed-off-by: Suren Baghdasaryan Reviewed-by: Vlastimil Babka Reviewed-by: Lorenzo Stoakes --- include/linux/mm.h | 12 +++--------- mm/memory.c | 14 ++++++++++++++ 2 files changed, 17 insertions(+), 9 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index cbb4e3dbbaed..3432756d95e6 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -787,6 +787,8 @@ static bool __is_vma_write_locked(struct vm_area_struct= *vma, unsigned int *mm_l return (vma->vm_lock_seq =3D=3D *mm_lock_seq); } =20 +void __vma_start_write(struct vm_area_struct *vma, unsigned int mm_lock_se= q); + /* * Begin writing to a VMA. * Exclude concurrent readers under the per-VMA lock until the currently @@ -799,15 +801,7 @@ static inline void vma_start_write(struct vm_area_stru= ct *vma) if (__is_vma_write_locked(vma, &mm_lock_seq)) return; =20 - down_write(&vma->vm_lock.lock); - /* - * We should use WRITE_ONCE() here because we can have concurrent reads - * from the early lockless pessimistic check in vma_start_read(). - * We don't really care about the correctness of that early check, but - * we should use WRITE_ONCE() for cleanliness and to keep KCSAN happy. - */ - WRITE_ONCE(vma->vm_lock_seq, mm_lock_seq); - up_write(&vma->vm_lock.lock); + __vma_start_write(vma, mm_lock_seq); } =20 static inline void vma_assert_write_locked(struct vm_area_struct *vma) diff --git a/mm/memory.c b/mm/memory.c index d0dee2282325..236fdecd44d6 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -6328,6 +6328,20 @@ struct vm_area_struct *lock_mm_and_find_vma(struct m= m_struct *mm, #endif =20 #ifdef CONFIG_PER_VMA_LOCK +void __vma_start_write(struct vm_area_struct *vma, unsigned int mm_lock_se= q) +{ + down_write(&vma->vm_lock.lock); + /* + * We should use WRITE_ONCE() here because we can have concurrent reads + * from the early lockless pessimistic check in vma_start_read(). + * We don't really care about the correctness of that early check, but + * we should use WRITE_ONCE() for cleanliness and to keep KCSAN happy. + */ + WRITE_ONCE(vma->vm_lock_seq, mm_lock_seq); + up_write(&vma->vm_lock.lock); +} +EXPORT_SYMBOL_GPL(__vma_start_write); + /* * Lookup and lock a VMA under RCU protection. Returned VMA is guaranteed = to be * stable and not isolated. If the VMA is not found or is being modified t= he --=20 2.47.1.613.gc27f4b7a9f-goog