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 E344BE7719A for ; Sat, 11 Jan 2025 11:24:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2CB4B6B007B; Sat, 11 Jan 2025 06:24:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2541D6B0082; Sat, 11 Jan 2025 06:24:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F5396B0083; Sat, 11 Jan 2025 06:24:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id DC8136B007B for ; Sat, 11 Jan 2025 06:24:44 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6B2ACC125F for ; Sat, 11 Jan 2025 11:24:44 +0000 (UTC) X-FDA: 82994938488.17.47919D1 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf01.hostedemail.com (Postfix) with ESMTP id 837FF40005 for ; Sat, 11 Jan 2025 11:24:42 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XAdq8XbX; spf=pass (imf01.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736594682; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0E7Rr0tz8d7Ig0WhGt4NA2wQfDoRZWvhhQcWVQIiTXw=; b=KDvTQ+bmR3fTIp9o/mIMYyxBB8ozw+/byPIN5XFtjy/kreoDN52Z2JORP+WrsUJExix6ia AwzuEbaciwLOwIDjY7NzD4RQwSJRRFSd7BqLmUlxXCGwRVhT3qvHsyvGSbXOOFcQqM/nfd IyhathPHQEJ+1gveEB/isFHuu4RojVY= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XAdq8XbX; spf=pass (imf01.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736594682; a=rsa-sha256; cv=none; b=Ye2t2lwVEgEHEPWosVAkE5DUAkyAdpbDSWLU4yE8ZjEL4k+Nq5ro/8EkqSLr7f7SY542K4 CYSjACvHRd00uGJqPFOt2IdLh8l9+qhv5UiEFcrbXThcpWBkuQlFfp0yr46z12odO2cq28 EqBrLpouiWoBh6swp7FptyBfddbX1bg= Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5d3bdccba49so4626329a12.1 for ; Sat, 11 Jan 2025 03:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736594681; x=1737199481; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0E7Rr0tz8d7Ig0WhGt4NA2wQfDoRZWvhhQcWVQIiTXw=; b=XAdq8XbXkG1tNt4e066w9tXpsY+k8B4rz9ZuQ45RCnF6UC2crIjGaEqUOPtNU3cthQ K7DTm9/NEBl+U2mm0FX9aBoTPV9JX3l/kBpJHLkyDn3U8houPVAVBYxJ1JieDniZgJ7g o488uY60L1S891dDCwHh4sxWDxfnT0H5Ny2WKSUMarv/5XDF2uggjVOtB84U7st+wkmU w6QvMNh15/UP571DbI/y8WNiYpGdCM5RrVyDXBv2ZBIeWUN6cRRtCxMkN5hontZzCOe5 8l8I2/HkgBIBWLe9tjuYY64qryu/HIbLSWumlIPefy1eN6xv9t8FMVq1l6JMgAxk7/8p WJmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736594681; x=1737199481; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0E7Rr0tz8d7Ig0WhGt4NA2wQfDoRZWvhhQcWVQIiTXw=; b=AvtpZOexeGT9P01lW3J0AL40M1AgJ3kHS1XzbxumS8AFKoVnCr60XUEBSOXhZKIBMy wwDvWHMiprvwPVmYAYjZRd7xTmCQem1P+eviAs2rjyK07Ix+GHDFGWgMWiwA1zBXzqKl VjhVpYID3aiRQPbXUy521hpp6iGX7qzeeaaLfHxDTelRoCBA90eV25SY8Rvb3DSfMg/r WKwUyvi0PM3Cn3Y8/hbPfBuA+qjnGKAv+pgVBHCHcs2wI15YbJUH+eL5bcr8a/9OScF7 av45pJgHPaEjcutaFHhxR0duaKFIP1lR3ecZPEreWzQST2D2Xrlsi3ZSBHLmANL32zuq KY0A== X-Forwarded-Encrypted: i=1; AJvYcCX/mjhfm1bplt2JE9/gfCxogZseh1+ThOZGg+/cfHg9v6z2qi3mfc1Is3kWLrb/yIF39oLqxp0bGQ==@kvack.org X-Gm-Message-State: AOJu0YzfrSRSQHtJvigb0RwURac5RbcvpMRjkPNjYrJcVQxX+WqUWj+F 6nJO7EhepE4WQ1XpDxMAQ0r1SFGeaW7uPw8Kl1EMcFyYmJKMD/ZR X-Gm-Gg: ASbGnctsNWK1ia71IqcCZgmB/zw7PmKrZFW6z99fyDsPhwn2EK5RNce3gzaoQ6JeGq+ VZpELsIPD/IzapUUf0YRb0/ITon1S9N07rd5Lodku+07EjfkT6G1EpQkhumJpJ62PS8Hw4wNyAB fme0dqbiHnZdKGHUtztcu50GtDwOlBghJEs8Ns4lCIpSh9BGkg5bOGy005tYWL+LSSW50YQ5EFg oVeQI/F7Lx+N+ls+DJRbu3eH3AQRaEqqIfS4EVzaOYDOi1jYPMtcwJRKUzt8goDJdwgEw== X-Google-Smtp-Source: AGHT+IG2/61nE3quv38DqgNG8ajW/3K1PH/G83ck3U2A5coY3Wq3xw4t+/hQEV2bOQFMxJDlXeyiIw== X-Received: by 2002:a05:6402:50c9:b0:5d9:a61:e7c9 with SMTP id 4fb4d7f45d1cf-5d972e1bf6fmr12749106a12.20.1736594680570; Sat, 11 Jan 2025 03:24:40 -0800 (PST) Received: from f (cst-prg-73-22.cust.vodafone.cz. [46.135.73.22]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d9904a4127sm2609233a12.77.2025.01.11.03.24.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Jan 2025 03:24:39 -0800 (PST) Date: Sat, 11 Jan 2025 12:24:29 +0100 From: Mateusz Guzik To: Suren Baghdasaryan Cc: 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, 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 Subject: Re: [PATCH v9 11/17] mm: replace vm_lock and detached flag with a reference count Message-ID: References: <20250111042604.3230628-1-surenb@google.com> <20250111042604.3230628-12-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20250111042604.3230628-12-surenb@google.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 837FF40005 X-Rspam-User: X-Stat-Signature: mtpmdus7xc6bntbjg7ttb1k6f8d8gsef X-HE-Tag: 1736594682-858346 X-HE-Meta: U2FsdGVkX19LVFnAY08pgjN1YhHhQg4cfKl+4VdyzJeibevV9tb4U13x66VdnPVVnw/i3BYs4dHNfjO0EMbLZzSFLux3P+XCePxYR9JVGv8AveZiRMlpQi/enKJDt4cRvuCXXyG505VeE5+1fYLYHZiovpq47Xd6TEUB4hHcJw84fRE4t336BrRXtaJoP6EfuHEiaQKfZc8fXVHnCjdq8C6NpNFIu+oRtpwNxxBLE0lT/Jbq5RUDWC4M/M3TZ/PTW0j+v6fIfJAfexPyb+Sx4umlkM/L3WF8zQ0B933DhX6WoFPc5/ZIUoPlvQijzkVrswBsQ9Z8yB/KnWKODy3U6FQEi82LdmiHB5U4Dd51RnkmZhCIqX1Tgk0jgJuSVG9YwLgnXygSdEI113lbFGCjVmdpKrRchqUGJriTsN+f+OwIQpk6BThCi2avV/TYYxGVdzfv08kfGL9N5DRo2h2MfyX7/J7DOcyNPyMZdH2vCLkElIt3JvFlnoto5tnv8L4aUwRO1MuACK+mk7BEphrmhIn6pfkBA4kdy97EExqCjdStXGmYBz/5V0gtOFgHblaH4+7988mN+lcDBT0+650FtZVxuIm/eV8r9Ho0oBvUr7aGYeEAhOAPrBvc1HwmgS88rKV8SAuk9Wrt26hTKK2Wc4p2wNLCtHr3zaKwQSxzirExp4jV28Hb0wz2BAkjJeQaZ9TRQZhum13R1miogLcJzqMDLD5qxVAcilFlIj3syZgBnqC9bjKJdjyMPgUeBnQndE3ap9wHBMoN1WtXwiQ6yyomLKS+cB/cyYDOzF4uIwO5Yktvsd9yR/LILg/HrJDKjlXBRsh7Tr1osT9M8dsTI9jXQa+j3LbP99j8xEDK08yn+yKML7sTIy8D4YyuFs+kiB75t2G/Wf46YA+ypSnpHyv8GuyuZiY3qAm6tPHdBvdvTkacE7eglcgA3iSWov9iUnbDHn886WLfZ1ca3pR ZXheVXC0 9Lx/iN56+l2WAmthtWhWIDL3BOZDxQ6mdBILshW93S5XgoOKxCSDfBJIR1NnlSK93l40Lx4Chi1dywRzQd2MHMkuH8phrsYjnVHwFseXEnXvq1c6oRvfMh/Z3CXmHap1n+1JbFPEYR251LnVq7SVDUBwQVHqz8L7lB7EalJ6QzA606K3H5LJa4CX1hnubcySNUi5kVPy7U5nkwhzHNvpNj6mWC2t6a/Mt0OSE8VS5HYzIC+8JAI0aGcG/9xoTjbdGVNMuQB+sWc4BTCYn+DjmEB3mU1i2NVolkHOIfFcQG68+VTkbpddkUtaUGIAfHVk5W1Vy1YPEwdIEHr6XtQ/to9LaTctWU/owg6+g2pdkG/HAJoWpDMuqdqVR6V9TMOLVSDw2BByphW1h2D2VWQY6tGAGC9gQUTOcdpRVsSERMgF9apzgFqY8fl9oBjJw6nnQcL7hhRNvNgmuxFG0HSghYSyZxJuaxYq+Da9DnPEggUO6zrg+9qFLmgzRZeJgVcxJPDvOT90mOhB9pAs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 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. :) > /* > * Try to read-lock a vma. The function is allowed to occasionally yield false > * locked result to avoid performance overhead, in which case we fall 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 result. > * 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_area_struct *vma) > if (READ_ONCE(vma->vm_lock_seq) == READ_ONCE(vma->vm_mm->mm_lock_seq.sequence)) > return false; > > - if (unlikely(down_read_trylock(&vma->vm_lock.lock) == 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. > + rwsem_acquire_read(&vma->vmlock_dep_map, 0, 1, _RET_IP_); > /* > - * Overflow might produce false locked result. > + * Overflow of vm_lock_seq/mm_lock_seq might produce false locked result. > * False unlocked result is impossible because we modify and check > - * vma->vm_lock_seq under vma->vm_lock protection and mm->mm_lock_seq > + * vma->vm_lock_seq under vma->vm_refcnt protection and mm->mm_lock_seq > * modification invalidates all existing locks. > * > * We must use ACQUIRE semantics for the mm_lock_seq so that if we are > @@ -735,9 +775,10 @@ static inline bool vma_start_read(struct vm_area_struct *vma) > * This pairs with RELEASE semantics in vma_end_write_all(). > */ > if (unlikely(vma->vm_lock_seq == raw_read_seqcount(&vma->vm_mm->mm_lock_seq))) { The previous modification of this spot to raw_read_seqcount loses the acquire fence, making the above comment not line up with the code. I don't know if the stock code (with down_read_trylock()) is correct as is -- looks fine for cursory reading fwiw. However, if it indeed works, the acquire fence stemming from the lock routine is a mandatory part of it afaics. I think the best way forward is to add a new refcount routine which ships with an acquire fence. Otherwise I would suggest: 1. a comment above __refcount_inc_not_zero_limited saying there is an acq fence issued later 2. smp_rmb() slapped between that and seq accesses If the now removed fence is somehow not needed, I think a comment explaining it is necessary. > @@ -813,36 +856,33 @@ static inline void vma_assert_write_locked(struct vm_area_struct *vma) > > static inline void vma_assert_locked(struct vm_area_struct *vma) > { > - if (!rwsem_is_locked(&vma->vm_lock.lock)) > + if (refcount_read(&vma->vm_refcnt) <= 1) > vma_assert_write_locked(vma); > } > This now forces the compiler to emit a load from vm_refcnt even if vma_assert_write_locked expands to nothing. iow this wants to hide behind the same stuff as vma_assert_write_locked.