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 562EEE77188 for ; Fri, 10 Jan 2025 16:07:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CDE026B00BB; Fri, 10 Jan 2025 11:07:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C66286B00C2; Fri, 10 Jan 2025 11:07:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB8866B00C3; Fri, 10 Jan 2025 11:07:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 45C266B00BB for ; Fri, 10 Jan 2025 11:07:55 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 254891A0C51 for ; Fri, 10 Jan 2025 16:07:51 +0000 (UTC) X-FDA: 82992023142.17.237E805 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf01.hostedemail.com (Postfix) with ESMTP id 3F83D40019 for ; Fri, 10 Jan 2025 16:07:48 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=c28fHwW+; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736525268; a=rsa-sha256; cv=none; b=eg2A8W07GBZ7cgDlHoguGUUeXwdYHYTUVEXdTZ2g51RgW0nHDQODkc7jb3CBnstZDkSH/n t3pGZ3C3D4uxX7DRBkbIaqMnIp9hy3J3pWQYVLENY6s3WUvsU1c066AVnlfj3pGVULQAfH 9YF74vziJc4vDnKn0EDPWvX1mOQ02ts= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=c28fHwW+; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.160.179 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=1736525268; 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=HuoSwo768mhftGn+VFoye9hxmZUgc0ATyWlHTOv+ogE=; b=cG7vHFnN07QrcbCIS7OStVB96HUt5snLQdcJ6JlzpdoEpVAqp0B3FCNSi8BK1eeqCEuu8B zks5SLBgS75jVJuy4GubK/9Elo+1tMU1+gIEitaEe15hqhO7SfOVkQU3LTNVNxUAVOWN0g qN2PqtVoWdnJ39zlFMNhQ0x8vUCouvk= Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-4678c9310afso229161cf.1 for ; Fri, 10 Jan 2025 08:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736525267; x=1737130067; 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=HuoSwo768mhftGn+VFoye9hxmZUgc0ATyWlHTOv+ogE=; b=c28fHwW+JMnkVLvRF+5BoTiBqBO/b3nEITg9BZPSWtHa0eZpejjUoU54oO4aav9F0S XdrTPZe/i/zcEO8xORaS2h8uipSkRaunlG+YSKN1mMdory4JJuI5XExB2PKNyKRao1zJ qRYmDVHNZesr23eJQbmf9oAM1zcmATj0cl7QIStPi8Gz0UKPvFE3cxEX36D4x0EIMPs5 bnN2j23qfjfyPe8mBMcgUWItBfaCi023j9zMpq0GxMcph8UFNTzzH7YcgwRo6a4pIE9R 0bo3M6IEvds0JHRQRm8JejE1Uow0Pm85UBgryL/VpjRjJCG+041qcQtPq8VUNQHBQL1p 4BYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736525267; x=1737130067; 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=HuoSwo768mhftGn+VFoye9hxmZUgc0ATyWlHTOv+ogE=; b=WV0Ai2Klf7xKGs0AXhUU99v3x8n4ISY8X9i9sL4S/bqAIEMEYUxq2UTyEmfO2inJ6y 4dmnMXpkFsLiuiREPtM6bpOSbexdhmJD02JfTLPHNGHj0IxM6s1HfHiHO7QM4Rb4mJGi qSjlgzAmnozkkWYiTfaOSP2v0fV72Dw9g100j4X/8pJK3ajwLxAiqrRib7cWJih9DHaR iPP2SZpPqYzG58aewiXnpMuJtp32db8Bjj0RkYzhDUFCktxpOs2P1ii7xDmJ62LX2Vmm /lkcnwkXwLjm+mdc0/PCxGhB7ZTehxmHz4Y02LV9Zac3ssfoYZDonIhZ3k6BpxpAeoZ8 T+oA== X-Forwarded-Encrypted: i=1; AJvYcCXyzWc/DJ37Mn2g+xlyvVAVZwp56ryEze9LstBvM90K+FVJtanCrpfxUZetF6mYA4anB1cwPsRvyQ==@kvack.org X-Gm-Message-State: AOJu0YzJZRwJ+fHwHpy6N2+ylepI/+smwu4LPiUR2/5Jkswy2x9a7wyx p7MzOZ/MRX96R4+wG8U4IXX2nk/5IPUQuJ38DILBY8HAys8jocLu8DDdtsgNe1iLmk1g3Z5luQF iwAwMk/zr4ExVeNDSQkTMSdNiAcj4RYoCCSDj X-Gm-Gg: ASbGncttKVSSxR8zAKliZS5nMD+nbSIAR6x/bHjeeOhh/v59oe9v6drWB7dfqIzsWO1 xDJcWqPshhZxNCPXKhZ0PevC4ehahzxxvNQNipQ== X-Google-Smtp-Source: AGHT+IHyV4k57UNejKjA2zCtXjcsUG+QSokEacjoANRn6PhX8p2751CgLfYsK6JB8hsH48QMqMho8xCXtXiibZlXmAI= X-Received: by 2002:ac8:5f0b:0:b0:467:84a1:df08 with SMTP id d75a77b69052e-46c89df3ccamr2973981cf.23.1736525267100; Fri, 10 Jan 2025 08:07:47 -0800 (PST) MIME-Version: 1.0 References: <20250109023025.2242447-1-surenb@google.com> <20250109023025.2242447-16-surenb@google.com> <41ebce1a-9cc0-471e-ac20-25efea9a933a@suse.cz> In-Reply-To: <41ebce1a-9cc0-471e-ac20-25efea9a933a@suse.cz> From: Suren Baghdasaryan Date: Fri, 10 Jan 2025 08:07:36 -0800 X-Gm-Features: AbW1kvbgpZuPEdva_E5IThJS2jJBJJsAW198oHHkkeTkV2QlMmxg9161lihYxSk Message-ID: Subject: Re: [PATCH v8 15/16] mm: make vma cache SLAB_TYPESAFE_BY_RCU To: Vlastimil Babka Cc: akpm@linux-foundation.org, peterz@infradead.org, willy@infradead.org, liam.howlett@oracle.com, lorenzo.stoakes@oracle.com, mhocko@suse.com, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 3F83D40019 X-Stat-Signature: 43k8883gwiuph7ri5fq6qqmc9s4nkcfk X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1736525268-916762 X-HE-Meta: U2FsdGVkX1+GaTqYHUtrKOf7LTos5Hh52dMzlhuYia6R7KngUPN0/kh1mazeBT8iPP2p7IT5yItA0DcvUdwEJbajQiCQLewB7C9y0Fg2mmwbWIoJG5Kb4uRX9NxBj4QZMWNwU3Pk48dePMsyLY3PIhn/Hr0KzxG3q3mxdikpBQOXb8n1QxeMEIrzOLGHEA0gbbWQnt7wQLniADtc3H29dx7MeEetXOVBXAZtZox2v7VFwFd4tnKkXj069RAy44CIGyxdLJqVuiKVm6HWWUTRoQph5NoBfsdAQcJycME3e8DkbDkWogHDdTwt9HwhfH9eQ1JJnkZvrAie6dTuT/82dBRvaHVqJiVTsEhrgZfjfZrx8u9b1tmG3NR+bvXz/fZ4Kazd9SeWbyPkeDiIIlaZzDxkBR559XU24eb2hwJMvlJJwrXKQ+cU5ffmoahQUiC8O5reIgh2T26B6eaXs00pJw6mNYKOI5U2BPh7Z/7QvE5OuKDy49hwSA6zUmw3nouSZ8SiMUvN4LhDTgBgiAwpzURfbhkjRUV0nH5MJhixoEZxbTkMjNe6SmzjMA57UuSagjQYov4TX9Y7BJCNhp49b/r8kLbRf/UM0oJlIad+qKzjhnTLnqFmaEuNOjj0bzejzPkDLUfgP0uwCLMFI6f5I8X5qcp2XOWesyqYPVYZzxisNQnjE9IeJNRsZliaSQBzqX2gLSNXWFTjcAhr9ZroEygSghY/7sBrDn8A2zLx6wSp7fcHjOyCXmqMyEqoMO+VCuWgG1pXgW2YJqeq6Ii+7HSC0S5xYx+LvxZjwnYszWjzxgRx9wbcNJad0QiW70pXM7MSwGBciAP284m2RSJ78RXVxG2fUDFeT8Tm+It6ED5CeZ60Y2TF0UKiCMhwGuj3ZAT7CqP3KLfYtDBMvPLwqYk5agzVVfuxezffD4LFurWb0k+D1E52widFI/CljCaPBYsXgyDGAJLfe5OdnBt 9+X9SuC1 IEske1cFphPyKFo7sX4FK3Y9//PX6wppOYANS5/KMkwg3dfajlb6UlGHNkfCUjxMTONk14bl3+vP0YFHnZcaYWBQVqbG5AUL+8gs5792ruydwL3QVSpebOh9u4lWBkawus/SNI0r62czu8jQ2aBTVFAGsAAO5ikHUwt4tw4V3kyVfLmt5jzxYk+gzw2M5ysS3GVuLD93+len/EpuWYpm+7WwdKH3q4wStgWwM+fE2WhNVIPTZIecXeTEVqa8OFMsm10B8SnT/qkJk4RON33unOfUTaO9SUuyjvSAniPXmispcmJPTVVhEti6yWMjISPa/qVcIxb3canxVz8gW0s70u/hg/A== 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 7:31=E2=80=AFAM Vlastimil Babka wr= ote: > > On 1/9/25 3:30 AM, Suren Baghdasaryan wrote: > > To enable SLAB_TYPESAFE_BY_RCU for vma cache we need to ensure that > > object reuse before RCU grace period is over will be detected by > > lock_vma_under_rcu(). > > Current checks are sufficient as long as vma is detached before it is > > freed. The only place this is not currently happening is in exit_mmap()= . > > Add the missing vma_mark_detached() in exit_mmap(). > > Another issue which might trick lock_vma_under_rcu() during vma reuse > > is vm_area_dup(), which copies the entire content of the vma into a new > > one, overriding new vma's vm_refcnt and temporarily making it appear as > > attached. This might trick a racing lock_vma_under_rcu() to operate on > > a reused vma if it found the vma before it got reused. To prevent this > > situation, we should ensure that vm_refcnt stays at detached state (0) > > when it is copied and advances to attached state only after it is added > > into the vma tree. Introduce vma_copy() which preserves new vma's > > vm_refcnt and use it in vm_area_dup(). Since all vmas are in detached > > state with no current readers when they are freed, lock_vma_under_rcu() > > will not be able to take vm_refcnt after vma got detached even if vma > > is reused. > > Finally, make vm_area_cachep SLAB_TYPESAFE_BY_RCU. This will facilitate > > vm_area_struct reuse and will minimize the number of call_rcu() calls. > > > > Signed-off-by: Suren Baghdasaryan > > Reviewed-by: Vlastimil Babka > > You could also drop the reset_refcnt parameter of vma_lock_init() now, > as the usage in vm_area_dup() should now be just setting 0 over 0. Maybe > a VM_WARN_ON if it's not 0 already? Yeah, that's a good idea. Will do. > And a comment in vm_area_struct definition to consider vma_copy() when > adding any new field? Sure, will add. > > > + /* > > + * src->shared.rb may be modified concurrently, but the clone > > + * will be reinitialized. > > + */ > > + data_race(memcpy(&dest->shared, &src->shared, sizeof(dest->shared= ))); > > The comment makes it sound as if we didn't need to do it at all? But I > didn't verify. If we do need it in some cases (i.e. the just allocated > vma might have garbage from previous lifetime, but src is well defined > and it's a case where it's not reinitialized afterwards) maybe the > comment should say? Or if it's either reinitialized later or zeroes at > src, we could memset() the zeroes instead of memcpying them, etc. I see vm_area_dup() being used in dup_mmap() and I think this comment is about this usage in case the src vma changes from under us. However, vm_area_dup() is also used when we simply duplicate an existing vma while holding an mmap_write_lock, like in __split_vma(). In these cases there is no possibility of a race and copied value should hold. Maybe I should amend this comment like this: /* * src->shared.rb may be modified concurrently when called from dup_mmap(), * but the clone will reinitialize it. */ WDYT? > >