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 14776E77188 for ; Wed, 8 Jan 2025 19:17:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F3866B007B; Wed, 8 Jan 2025 14:17:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 679516B0083; Wed, 8 Jan 2025 14:17:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F3486B0085; Wed, 8 Jan 2025 14:17:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 2B40E6B007B for ; Wed, 8 Jan 2025 14:17:28 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B165881392 for ; Wed, 8 Jan 2025 19:17:27 +0000 (UTC) X-FDA: 82985243334.21.6D533ED Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf23.hostedemail.com (Postfix) with ESMTP id C0A25140016 for ; Wed, 8 Jan 2025 19:17:25 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=hyi9dnKI; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 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=1736363845; 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=BuDJhrl4BaQcccQ0ggv6/6Artahh68C0TXyt6JOc41Y=; b=5UUew7TelJTDwa8235yZQ8Cqh1VJe4/ezX+uRYlTEkTR+V2Tnx7lhjbXy0qtxZfGgl6gRh 0czJ2eWTb+Fxvm4Da+clmQxziIdEb7PpWVCEjZhMIrlb5psfRTbmxNOQJS2aSOB4/wJCch sk/nkvGW+uKzerOYhNZ7LdiI7vn8BfA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736363845; a=rsa-sha256; cv=none; b=hQLetPBVMHAFnWVDMX5+UWw5aa6/+73m5KXscYUcbxoikNA3Eu01/V/Blo6dGgXWDvblaT Ls1jvznLNWAqNMCXfzilvjejLCB2sVOMGmnFiVlxBH2xA7P+NgzVHscJ7atAYSbozwBb7C rHy2pRP39Q65m7KU2X9qXD9Crd3ZawU= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=hyi9dnKI; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-467896541e1so32061cf.0 for ; Wed, 08 Jan 2025 11:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736363845; x=1736968645; 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=BuDJhrl4BaQcccQ0ggv6/6Artahh68C0TXyt6JOc41Y=; b=hyi9dnKIt6ReeXZ5fGuWVBIdvGyTjcBQJvWQ6FQETI4Go/S8hKbMsW6k6eBoEAzNAG Y8A0ejX0hYp7oRzgMeJQsJMdLaVIcO2hby7gbRz7H3GRzOI7lbvGSVAASzYaJ7GShaZA M5cKMGm4oALxCeSBspCj7JCUMmEmG1E4RnhV6DpMTPF8pvSuMg2f2NYxNoJ2Yf57+67C lsC5D5kIIF5qNjZe6Hke3fJiWzqwaqMv1PSVdfLyLH4XomFPXO1vzOBG/DwngxgzA6/x 6WnEVBIq4rHpZexjiPP/B7RWpdYrr1Y6X4ERrmkjvoZ0ebvDZ/ed1LmA4/pODTqZGKU9 IxvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736363845; x=1736968645; 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=BuDJhrl4BaQcccQ0ggv6/6Artahh68C0TXyt6JOc41Y=; b=fyAbfXTXlVEV0D4HmUmOeOJCdsAchuiPbeTjY4OLTHmnhWhwmyHEto5RJVGDsZPoIk l+H8Hv78rhX9ydh3iVevEc3o/PRUQk/P0o0KGHIPc1xXJTijD5DhlSwnDoxXXOBfxlx6 GvRcLVosD6KcJtp4Q3k7sQYdmJOYVQuZAhEke0JqjxaMb3SEwgmdD9CFRxkBtvl2xSrc 4TseEjWDswO4XR1VLFCU2EfU353puAUuplE1Ivq4B3HkVbMQHeTVsx9hMsjOXA1T6If/ fHtrCTykz3n7TwNy6rw+cnwPpRohpPq1bPVXld7fCtNvC95xpJnUIOx87cUpmvdh7sgS zylw== X-Forwarded-Encrypted: i=1; AJvYcCVjOPt7Qri32l/cL0Zu1ez1y7uOS32DlNTfYtGz7ONOqgCn8gf0BNQLJWeEivTpH99GNbmDh7BbEg==@kvack.org X-Gm-Message-State: AOJu0Yx2zaeu11av4SyKsI7aWeUVB3lId/K4MeiSCfzaaSJorPjNibTn TmelZPruQ8INR7F+6vRVVgr5btFc2tJhxGdgVi+pTz+9IrtC/DZ8ydXG0Adxi5VNFRL82DxyHUd eMuvqfhOWGcDabxq8o2JkMHRoZx9mWfP2woML X-Gm-Gg: ASbGncvqN/YBIKXNenn/NK3JsfhpupkjHscxc1wylFtPgaIdtXUluJ2+Pq3yiAo+Pb1 DY/cla2kKVPMX521XO4+v1moZ1VGyWSNVsNqePDhavqXyVTOL5TphjxnjilDE7ITPpho= X-Google-Smtp-Source: AGHT+IEWKfjb2sJGpu5As1nzg8K1rKZqtSGnRBmo21D1OvbVa57GrwHS6ccA8uzqF1PCvrQDPTvyug79TWwkzzBUD6c= X-Received: by 2002:ac8:7fc2:0:b0:460:4620:232b with SMTP id d75a77b69052e-46c7bef3f7amr141631cf.28.1736363844616; Wed, 08 Jan 2025 11:17:24 -0800 (PST) MIME-Version: 1.0 References: <20241226170710.1159679-1-surenb@google.com> <20241226170710.1159679-17-surenb@google.com> <5bbc5573-4a10-4c89-bc69-6cf6117be915@suse.cz> <22c002b5-9aca-460b-90fb-772adb9e5f61@suse.cz> In-Reply-To: <22c002b5-9aca-460b-90fb-772adb9e5f61@suse.cz> From: Suren Baghdasaryan Date: Wed, 8 Jan 2025 11:17:13 -0800 X-Gm-Features: AbW1kvYUlotPCa6SD_1FT8EQdIWNRV6GJbNS5R6FvwKXbg9KHLyiDGnzc2umO20 Message-ID: Subject: Re: [PATCH v7 16/17] 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, 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: C0A25140016 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: u57zxdmeaik846kxgb7c4erck96gtjki X-HE-Tag: 1736363845-924484 X-HE-Meta: U2FsdGVkX18KxsfvDsG4BseSNGcvaFHyTcMf0Q7Tb3bFtHpu5eiIoAhmgy6WRWzr7r9e1h3CktnRFYVxW5M9IaTqG4P03a/u9LKCVPc9Z4Jz44Ru53zSKI/pGHfdztr6V5G27cDgAnydns+psYh9uv/YJilLo7qUkdeQJjutjhE88LiH65yTNWqA5erhPhkWN8qFjkaNN0bK0u1CIKoyha8kgax8xlmylNzniu2hpf08JHaH56m2UkNA5DjDhXi5MdbEh2dHYICUqowKARbY0GeKLzBnKfWBl+lsNcSOmMgBhT1/pny0a3wBc8MTEyfgN/HVWHngW1OsORurKOB+uP+lFiv+K1sf2Fz2F5AqqQ/t8P+4QyCHcIiyCNgwwTP455fY6nnNQmpeU1jHeyu3D0rmJrc6C8PINgBkMHoI1X7qxYZt/COfnruRUVkaSVEo8NXOoX4TtEJkWrrNPIsyhA6DdE20JVBeeFozG1k85mCtMWlL0U3bUQ/VdXRHAE0vnh3w4rZeLfp8nzBz+3XJUycw4SsFtmb52p7cSSru4UaNp+NKaZ1Nee5Q55SMyAsB1tRE5VJaY8b3yT+SqlDsP4y4MYkh9NiCL4x6UL2xUJq9YLAuDMxtmGeZC7l37/BZ68QdzvEF5yKs6BHMXBmpwKc6AcLYUnxs2IK6mmQTurVGxSLluKk6CJYGrHcpUi6f00XQBgfVEvWD9GlxjjNvUsBgP5jN209zdhMj8PZ0bYReqkK7Kkpa5tdeEbbDUugglE00Sp6WQonpYRyOtHPOrG6JRI5PmOzNOHKA9ahQbqFhqQ2ZHijUW6W3IQpOJmNDBKJ2Cr+T8ot6H8hd+h2SSHWyipnGRd02Et9xOCWgZjaU1Z1sI3Dbb0uiaErhWO7MpBeIrN0ySJz4KNUm/kx3nbGwutnGKbrUeucQKqq3dxkuYAq8bCVLZwdscslJHRtAuY7T+RDSmqNdpVUmywy C5f0ezyu 4xpoodgjOPYr8naRaj56lyp04YZBo7SG/BoyCxG4k9luNEeOq3fGETD/ZPMoVQHuzGD9dz6VeBwva/m3oLSYnwV+unlpZQRmu3EbHXCzOZ2pY/vImp1YY3IhTMbFnXPyOC7FtyK3nIS78rfkQyp4NtlDUJJVL4hKIYFSExqLOk2ni9nOzO4k/srHod6owktbo/csxbZs2hEg5aTzb9g708WDaYPDpjbW0YVpYjNfimNdokPe/opVhk85YJgf7SZGqCM9bDfzxD/jVVvw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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 Wed, Jan 8, 2025 at 11:00=E2=80=AFAM Vlastimil Babka wr= ote: > > On 1/8/25 19:44, Suren Baghdasaryan wrote: > > On Wed, Jan 8, 2025 at 10:21=E2=80=AFAM Vlastimil Babka wrote: > >> > >> On 12/26/24 18:07, 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. Implement this guarantee by calling > >> > vma_ensure_detached() before vma is freed and 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 > >> > >> I've noticed vm_area_dup() went back to the approach of "we memcpy > >> everything including vma_lock and detached (now the vm_refcnt) followe= d by a > >> vma_init_lock(..., true) that does refcount_set(&vma->vm_refcnt, 0); > >> Is that now safe against a racing lock_vma_under_rcu()? I think it's n= ot? > > > > I think it's safe because vma created by vm_area_dup() is not in the > > vma tree yet, so lock_vma_under_rcu() does not see it until it's added > > into the tree. Note also that at the time when the new vma gets added > > into the tree, the vma has to be write-locked > > (vma_iter_store()->vma_mark_attached()->vma_assert_write_locked()). > > So, lock_vma_under_rcu() won't use the new vma even after it's added > > into the tree until we unlock the vma. > > > What about something like this, where vma starts out as attached as thus > reachable: Huh, very clever sequence. > > A: B: C: > lock_vma_under_rcu() > vma =3D mas_walk() > vma_start_read() > vm_lock_seq =3D=3D mm->mm_lock_seq.sequence > vma_start_write > vma detached and freed > > vm_area_dup() > - vma reallocated > - memcpy() copies non-zero refcnt from or= ig > > __refcount_inc_not_zero_limited() succeeds > > vma_init_lock(); > refcount_set(&vma->vm_refcnt, 0); > > - vm_lock_seq validation fails (could it even succeed?) It can succeed if task C drops the vma write-lock before A validates vm_lock_seq. > vma_refcount_put(vma); > __refcount_dec_and_test makes refcount -1 Yeah, I guess I will have to keep vm_refcnt at 0 across reuse, so memcpy() in vm_area_dup() should be replaced. I'll make the changes. Thanks for analyzing this, Vlastimil! > > >