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 711B4E77188 for ; Wed, 8 Jan 2025 18:44:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F41736B007B; Wed, 8 Jan 2025 13:44:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F18886B0083; Wed, 8 Jan 2025 13:44:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE0686B0089; Wed, 8 Jan 2025 13:44:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BEBF16B007B for ; Wed, 8 Jan 2025 13:44:54 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7E4D11C815C for ; Wed, 8 Jan 2025 18:44:54 +0000 (UTC) X-FDA: 82985161308.17.393F109 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf09.hostedemail.com (Postfix) with ESMTP id 9CBB714000B for ; Wed, 8 Jan 2025 18:44:52 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=NKso5NHW; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of surenb@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736361892; 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=wnNXpbhyNwqWJLpKxproE1/kJYxyfgxK3iF+68CQzjE=; b=VzQBDZpVGy9lpX45rDMZ+8RAmRw8840oGbKx3GUSDxPu0FwwK3JMvVWJ6lREhYO2Rfgspe vuIkJXxLFzmZhPa5OFmiZI1bszWZGtuRapkr7jLcAFqKyrYOGxWK/dNa2HiPeJNYwVOy6j lQuDXnHGx66JcGOmnwFmZ7wLP0Fcf0g= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736361892; a=rsa-sha256; cv=none; b=t+muMPCsdf6Efv0jKRyPciEtzy1Xzhr8fLuWgdO5w8jJGYA/AgD4Y0axSoRXZPRcAGt4R0 nWzwyK01Q9YbnySwM6vthVegNrGq9n2lHixHPkvc29P4oehWwLKs7vWeD1W8USQFyroJQZ iuADWjZRJVFJis0f+jDYB9A0NiHMyqQ= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=NKso5NHW; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of surenb@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=surenb@google.com Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-4678c9310afso15521cf.1 for ; Wed, 08 Jan 2025 10:44:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736361892; x=1736966692; 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=wnNXpbhyNwqWJLpKxproE1/kJYxyfgxK3iF+68CQzjE=; b=NKso5NHWqVhwMJezLAbUc8KaqdUDkhPlBrEIoSoZP7FTXAx4UxU8OHJZDZ/pdfxCHB iImL6y2cJns6qmpC/vNs+6IvW+LoXDazVVACA78ERojnFP++izCrkCfWTetuY+btpggw gSkLiH6d12Wcp81ZDO73Jvm5zVMIwVsrW07ZbLhN6bhnv1YN/DIbUjFqVg3vICtIHj/p Vb+IT3my1S0tdj3eF9m7LE9CLJ8w9+o66GRP4Sz6JWoIkQBLueFcqKgRqTNvNOU4hIB7 MzuKo6isvpbkcObGksXxVYLqsg6Z2CVzOc2ZjLoTm7OHseYWak7e+iJt3VSd56sQCnBw uDHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736361892; x=1736966692; 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=wnNXpbhyNwqWJLpKxproE1/kJYxyfgxK3iF+68CQzjE=; b=wa2vwKU3Kq8r5aYfkG9m/uEcXYwTJf9/sIvzPEyZCwk3ikYJ461fzuXu+SAV2NN75o YSDO6tV91kDmyVf2W5HxMtmmskcY9nqd8PNH+9MuqEgIbtOl6l94hYgZOPOyj6K5HoI7 9cAYIzqAJgMBoZvMqW+7jbdR2wdbWA7vcUbeJ6qbQ/f6x9ldJSedJ5ckQeAlqhmeQ2Aq X3+lit1dkgrN9d9X/s1fkMSGKKQy7n9rHcdVNXEGCc3bHyIGjfqCz4GMzM2+9qixAt90 LQPNkD/VivMUuTp91EAILnvE6qSO04hSvbkY/DFzAlNuc+HIxpMT2Qqt8IyfJKY7okHi mQDw== X-Forwarded-Encrypted: i=1; AJvYcCVLqiWPHf6qXYgjT+fGdnBUm9mOZsH5vd/w7A9rOp7ZHn/SqjVhoPY/eIpe0dE8qiemp2tHv4t6Bw==@kvack.org X-Gm-Message-State: AOJu0YzkhZe/Uv5T+z5QU/xpjyQbuWVU/BJXbl0wUuZ+Uo3GlxQDztM3 p3unnDzleXFSI2fcV1CowspyyPTamJhRTw27g9Hyp0sdkckSLc0PXhGixWhAjjOPlsLJqczhhfg 6lZpODI9AJ/bhHIceHl7hhO/foVl120qp/HEM X-Gm-Gg: ASbGncs8VojTMqja0gCBXL4M8PmJmLXBRg+Te6gFmpZyyhRsWTpvAEzy27qhoo6jw2Q NKxobKeoALD243V76Quaq2kBM/bN+6XG9W7VtTI/GoAeHn1vH44JCRTJyD3104Qdfik8P X-Google-Smtp-Source: AGHT+IEiT25r4zaPYjs7EApupiu3gAbk5yx9BHepynrH9N0vhldxsBjDR/6bMNk5v72iixf203/gTJw4z0A21rcSMWI= X-Received: by 2002:ac8:7fd4:0:b0:465:3d28:8c02 with SMTP id d75a77b69052e-46c70cb7681mr4832691cf.26.1736361891470; Wed, 08 Jan 2025 10:44:51 -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> In-Reply-To: <5bbc5573-4a10-4c89-bc69-6cf6117be915@suse.cz> From: Suren Baghdasaryan Date: Wed, 8 Jan 2025 10:44:40 -0800 X-Gm-Features: AbW1kvYF8IwbD9gyfW8gY7iF95gJMwWhtwOqJogiE6ao-SlOl9enC8UdLjJ2kuU 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-Stat-Signature: bswz9o5q388cp19zqdkjtxi8755ojakn X-Rspamd-Queue-Id: 9CBB714000B X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1736361892-98825 X-HE-Meta: U2FsdGVkX19sgcowHlCCSYrsS+hkw65LRLx9WkIgz1IFtR8zrLqPHmRv/WLPsOKF2GqX1AXVyHyJwEMaE86D8HScECRVX/fuvz57mwz/3MQDqC0YxVF8u54NccpjRx9TYDSSMfQUS13Ovs/xec+Yf/aViHOEvJfteHncnpzc5F/9+MBcPZ+nA16HooHEIEazl1xUKMhVfg/UjzHwj1u4gOQyGGa9NVmDMxT98Xla2gADFjNfofP03bglSQMbJykEbtWfdixamIN7zpNzDQ/dLwNOmDtCHMjE87nvKqNA78C3e7NMcf9g3KmhENVdXNoE7C1bsNBXWIF25KpQ5SEA3B/F6i9nqygukQm/BqAa6Im5Rkc2K07ZSy7TM+ZxV+FPfzkbCD90sfZDZiiPUak+H7y0awtHxaMYw85G9B9IeIJdMjSrm0tnH3pUdhn56L9q1RsEOZrOtgTP9/1DmbDzBRWJqbF0MGsZ6HVgI1Yiqw1AjMyle2Kkq4FRgcHmAN+IzGWfoIVRfEizzLlByr0XXUSJ+3vDkXxy58tVnNNbpa6zaC3SpQukhZtqWhvUDUiGJaSrLscZg09a+8C7230tYip+s5vvGEW+HuUMvV5dYohxBKu74p5CiLY6ZTGgyuGHbdiBQzbB+gnrv66ojVRMHtqUZakf6wzQbYkEs6RNMT1vuM+ict28H583HXHuTnmI6XrsB+e4e839qLAVtTdvlJw6jMfIczq0vP3j9x9h6Rb6zdrDem+TqApxwoP/Hj5HmRB4XkCa1Y8U/Rbeg7x8a9q7nFYAvpb12Teao3+mGhZqbRp34E97lWhS86y9uUmNBMxKE9L52QvzndfzWowiYiY6od9Q4+x35vxeHJwjt5D6S8ptlQzvQEOo2rtXjTQkcSOkONgETfHDW+/CeGxWiCYlTKu0XF0CJqP/XxtjjvsDLggv6V7DCzg2CZk9UE5fXdX7rh3KTKoG3h3TE3r FA4+te// 5tgoyk2b+mmLzFHTiFQf4G5x5HKK1AZlJCgMx5IXaFzQzv7bpzIvLh1n7mCQtAO0tbIM6H387rgW+yCydBJgjUugU/cfK3Gew6LRBJfFh+Pt/ndWRo6aYDFjNDQkMC6Ly6V7KkO4v6JGMNJVt7La2CyjV4EK/IHDMYkMJsSN4X4n+ZbO+ofDmqpF35FjuBFWtKg3ugRtHT4Ss0gj+JttDbqaEt/PT6gnbzkfFQ0oE7mMS10mxadX7Ol1hlSmiX911VzGCL+95nQFTFek= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000043, 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 10:21=E2=80=AFAM Vlastimil Babka wr= ote: > > 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) followed b= y 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 not? 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. >