From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AB52DC02180 for ; Mon, 13 Jan 2025 21:14:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D6CC6B0095; Mon, 13 Jan 2025 16:14:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 385846B0093; Mon, 13 Jan 2025 16:14:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 274B26B0095; Mon, 13 Jan 2025 16:14:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 065786B0088 for ; Mon, 13 Jan 2025 16:14:43 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id AF3CC80344 for ; Mon, 13 Jan 2025 21:14:42 +0000 (UTC) X-FDA: 83003682804.17.3AE08AC Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf07.hostedemail.com (Postfix) with ESMTP id DE6FB40008 for ; Mon, 13 Jan 2025 21:14:40 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="YzQEnj/T"; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736802880; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HGjAxZWeoR4eIf6Vg1CVCHX5fLV66MedHmHZbmp5W/0=; b=6DV2S6gZun4c5So23zUYiLG3T3mAYrWKU3lfBY7gWgwIakmVdoTnou+WpteyJfImkIZeW8 ZQox+7yxV3USL76Yn9NfvExIhLVpu1d+uQDvCNHWTzwpWH0aC1dj798KCwRg3V93+hs7Pf s/tbvqxB93sLJ6np92BJ4FJYrjc7Lcc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736802880; a=rsa-sha256; cv=none; b=VB7h9vc3WmbwlPRUaev0VvIcb5cFCBfqj6ObQBmAHZUN+d/F/aZwsnSiQh+abW9AfkRUQI rO2OtF/cIBnwHSH7MTZVsoWuv6M4SCOLJSj2/5c2b4GM7c0TS9mYo2bg1An0la4wxgRcE4 EuI9+nyWWqz6Nptex+B+Sj1BLkxgnTo= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="YzQEnj/T"; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-467896541e1so65991cf.0 for ; Mon, 13 Jan 2025 13:14:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736802880; x=1737407680; darn=kvack.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=HGjAxZWeoR4eIf6Vg1CVCHX5fLV66MedHmHZbmp5W/0=; b=YzQEnj/TCcH2ICWkMoIVvodzFgbAJLes2lmAmGfYrbqHQ29vpj42+bQK3nXCfQzYXQ +iYJIPjU5z2HqmuE59RtwVXqT0VLOEkx7L+RUEAHp1Db4Nn+4SyZ3M2p2kgpvc6xhdJu xhjmuK4IYnzjUwBc2+1eoHccXeVbDRyliue/dlgSe9MjHFlwlySb6KOg6AsFWsQxhe7e vEPK++g8zI2mr879HCyOO0T7oRAHLqTtSGYdU3G4+x6lPE3BuPJ6BFwlkBmsWSDV30kP PJwuNFUY+R+ed9QwmHqlci31Sh2dk+MoCzOTIYDvomKtCf0FG2TIBFdYcH3nMEJorcow 1vWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736802880; x=1737407680; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HGjAxZWeoR4eIf6Vg1CVCHX5fLV66MedHmHZbmp5W/0=; b=CZV2ol1Olcr+AnVUVUYZQ2J+yflzNnYJbjio0kR5yTvnL+QwebppfxrCDFdIOpkjdw vl74XKfnxeld9ZELZnatl1yqnCIjc407wCjgx15sBkJGaRLy+0+L41CdGE/xZI8Dy8L5 UKbRJNbOfQ9/fiu1Ol0vy+dcpNQQ1hZbZqir/9YrlouaPgPNx0wMj7jTy8oWqkbKXng9 J2XR1nRx6mb6ERv9u+kXU4PKMCoulU512KwN80s0GHqZIDChavhBmHIb55dX7BJOL+Ll tB7EV+FyjtzzIuExligmVfFVYjQqGqxD50RBc1Gi4gNLq/bdj4bHA2Zx7dDbQQedqMOt uEdg== X-Forwarded-Encrypted: i=1; AJvYcCXx6mllTTPWrNQJiomW4ShP2oSgwKhRqYw9EPR4tsKWYud7G+2WwPm6RwCqzfNdfdv0Abfbl6kdBA==@kvack.org X-Gm-Message-State: AOJu0Yz2vuNqZwWvp9zYfn2yBMJgV3rvg7ZPBflUWyYmD2NcSKVCDaqJ 8GXlGWcKLfbOmSU0BhLKm1qhnMBJUgbf/LQjsttmnN9aznKMYXrzVK+stOr1OT6neI5ZpHBpije haW5C4TAGjt2QQD+be6vVA3jWWSmQtze++e6N X-Gm-Gg: ASbGncvocPF3y8560EPTs3ivJydQaf3dyhh22PbeE2gmoUsIdE1huLRJ81THpZzC9J5 PRaVTY7xEFC1sntcCJ/BN+KcbCAI8pUSHhfkYNw== X-Google-Smtp-Source: AGHT+IFqAHFj/WuITWcnJw0D7SXwO5J6urUwH0ERPP4GcRKHt1QNDBndCsxDS0ry+WgFlJY6haMyPc6RKz2I8foTck8= X-Received: by 2002:a05:622a:1907:b0:465:18f3:79cc with SMTP id d75a77b69052e-46de99be6admr516171cf.11.1736802879667; Mon, 13 Jan 2025 13:14:39 -0800 (PST) MIME-Version: 1.0 References: <20250111042604.3230628-1-surenb@google.com> <20250111042604.3230628-12-surenb@google.com> <20250113014729.ms5sdfnhynlamgrk@master> <20250113022545.56e2qaggdgqzlukz@master> In-Reply-To: <20250113022545.56e2qaggdgqzlukz@master> From: Suren Baghdasaryan Date: Mon, 13 Jan 2025 13:14:28 -0800 X-Gm-Features: AbW1kvaF5imeB8Llt20RxA_EepFLh2dl-i0UYq1OwEZlpBTwFdjifQbVhR-9Npw Message-ID: Subject: Re: [PATCH v9 11/17] mm: replace vm_lock and detached flag with a reference count To: Wei Yang Cc: Mateusz Guzik , akpm@linux-foundation.org, 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, 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, corbet@lwn.net, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: DE6FB40008 X-Stat-Signature: k7w3hhb8eygrtsgaz16ipymnkz19w7n5 X-Rspam-User: X-HE-Tag: 1736802880-934396 X-HE-Meta: U2FsdGVkX19Oa0bu1ndVObO/kb0XS29fdgPNdnDkPamEyX3NgfyfXPmmKP3kIbWSKsSKhEGHUC0PWV4v2OLVZIBk76h/dPSZTCPs28cgFG92dT/rcXiMPPG2pP5lH4MymqUN5OAb9xDY6oL1asYb8P3t/sBSShgm/Mj2xfdB7POAR4THRnHg22zSbreG4CBZSEgg1u+w/BldK47LK/UPMzcNtaM+2TDu2ubXeVphWK13Gs1Mtc5ILa9YG3cHCurABKXIN24fTn2OX0Eeikk8oFX/c9t5uy/mRsg9syNJxpFFDJ8tzxz1vkPGuW76gqcjGo4KYla5bPABL7oRwzqjC6WpFuViKLk4gmQzJC+8BizoenJ3hArSM2Z5ECEDuT59qb+lY8JTiJVwXkR0beuM4jsKdH4rRZ8rbq1+CxxWtVlE9ckLz73GFA4waw6z8jYCP9MdR5Aj77PxcwW6b2aM+ubQRTJRZxAvlE+624DB6NBq1S5f4Z+Ip1krWTU+U10SsiqOO3hfU909gHp3NwSHZhmTrbmSjg4ZANMmLo/NSFbnmMv3h6lbgOQzCMdhUFfhH8ff2M88JyHcs+pvkNoJC+t7lTk4dZ8z4L+rQR1Mzz1s3EJ5ZHND4bcgWOl5FWp9XJgjfe9PLy33kNc0dsVSfJfb6KkXc6IIIPpU+TQL1ef2rHfkbK4/tfdE/+iDXgyyMBZnYJjoGjg7Enj66G4ubbSoI7L3keiX+UUBa2f2+8I2UHj/IrcYXx72cXvvE3yXBufEGRG5Rbbqjbw7NJIp1DEGYxendTLeJSTFAVMqDdcfWc/6bghc8pSnz00d2OVmPeThZFDb4ZYBFR6AiKfewO++7QeuirU+UP9sE7M5w3QVBksYqxexgFZFqHBu5fsyaHMPOxfCgcS3AA9e6ON7gWbzqlQZoaH4UAiOxmYVvgvry7WIsrRL+3lrNRZLxucjV+Zc0xXTKcsIvl/h2vq dO3FkIoQ LPFka8E+E7NcV29rCkE6txOY4W8ZjtgACvF2ZOcaI7hAKBkq62oKdW3mcz0O7KRMipXQd0KbT0YyFYelibM1w6k9EtThxps2WN6e5niJK2VN9lAklAZMvTujq1meAXxRhRKNES77KR9cLALcEhJmT17XhZakU5povW1EkeTpkcsdUB9AHNW3UhK3DReFbMJsn0e/oL26wAVaFBwXrii+B93KlSUDsZGbMtuJ7xwAoHAnVm33YOEIYGY5Nf9M/+XlGychXko4oYFMXXL0KQl41aoQKULlHsSunGAGZemomfLIwCdAy+OTsxgPxrBDycr7sl+/snR390TgCYBr9E1/Vq6Idg9qvQYQ3tqd24JywVv6qamlAvbe/QmNbf/3q/cWScsLHZKhM97u1Hmw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000849, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sun, Jan 12, 2025 at 6:25=E2=80=AFPM Wei Yang wrote: > > On Mon, Jan 13, 2025 at 01:47:29AM +0000, Wei Yang wrote: > >On Sat, Jan 11, 2025 at 12:14:47PM -0800, Suren Baghdasaryan wrote: > >>On Sat, Jan 11, 2025 at 3:24=E2=80=AFAM Mateusz Guzik wrote: > >>> > >>> On Fri, Jan 10, 2025 at 08:25:58PM -0800, Suren Baghdasaryan wrote: > >>> > >>> So there were quite a few iterations of the patch and I have not been > >>> reading majority of the feedback, so it may be I missed something, > >>> apologies upfront. :) > >>> > > > >Hi, I am new to memory barriers. Hope not bothering. > > > >>> > /* > >>> > * Try to read-lock a vma. The function is allowed to occasionally= yield false > >>> > * locked result to avoid performance overhead, in which case we f= all back to > >>> > @@ -710,6 +742,8 @@ static inline void vma_lock_init(struct vm_area= _struct *vma) > >>> > */ > >>> > static inline bool vma_start_read(struct vm_area_struct *vma) > >>> > { > >>> > + int oldcnt; > >>> > + > >>> > /* > >>> > * Check before locking. A race might cause false locked resu= lt. > >>> > * We can use READ_ONCE() for the mm_lock_seq here, and don't= need > >>> > @@ -720,13 +754,19 @@ static inline bool vma_start_read(struct vm_a= rea_struct *vma) > >>> > if (READ_ONCE(vma->vm_lock_seq) =3D=3D READ_ONCE(vma->vm_mm->= mm_lock_seq.sequence)) > >>> > return false; > >>> > > >>> > - if (unlikely(down_read_trylock(&vma->vm_lock.lock) =3D=3D 0)) > >>> > + /* > >>> > + * If VMA_LOCK_OFFSET is set, __refcount_inc_not_zero_limited= () will fail > >>> > + * because VMA_REF_LIMIT is less than VMA_LOCK_OFFSET. > >>> > + */ > >>> > + if (unlikely(!__refcount_inc_not_zero_limited(&vma->vm_refcnt= , &oldcnt, > >>> > + VMA_REF_LIMIT))= ) > >>> > return false; > >>> > > >>> > >>> Replacing down_read_trylock() with the new routine loses an acquire > >>> fence. That alone is not a problem, but see below. > >> > >>Hmm. I think this acquire fence is actually necessary. We don't want > >>the later vm_lock_seq check to be reordered and happen before we take > >>the refcount. Otherwise this might happen: > >> > >>reader writer > >>if (vm_lock_seq =3D=3D mm_lock_seq) // check got reordered > >> return false; > >> vm_refcnt +=3D VMA_LOCK_OFFSET > >> vm_lock_seq =3D=3D mm_lock_seq > >> vm_refcnt -=3D VMA_LOCK_OFFSET > >>if (!__refcount_inc_not_zero_limited()) > >> return false; > >> > >>Both reader's checks will pass and the reader would read-lock a vma > >>that was write-locked. > >> > > > >Here what we plan to do is define __refcount_inc_not_zero_limited() with > >acquire fence, e.g. with atomic_try_cmpxchg_acquire(), right? > > > > BTW, usually we pair acquire with release. > > The __vma_start_write() provide release fence when locked, so for this pa= rt > we are ok, right? Yes, __vma_start_write() -> __vma_exit_locked() -> refcount_sub_and_test() and this function provides release memory ordering, see https://elixir.bootlin.com/linux/v6.12.6/source/include/linux= /refcount.h#L289 > > > -- > Wei Yang > Help you, Help me