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 32922D41C07 for ; Wed, 13 Nov 2024 06:04:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ADBDC6B00B5; Wed, 13 Nov 2024 01:04:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A8AC76B00B7; Wed, 13 Nov 2024 01:04:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92B7E6B00B8; Wed, 13 Nov 2024 01:04:13 -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 6D3986B00B5 for ; Wed, 13 Nov 2024 01:04:13 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 28E60A084B for ; Wed, 13 Nov 2024 06:04:13 +0000 (UTC) X-FDA: 82780030578.05.9C08834 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by imf14.hostedemail.com (Postfix) with ESMTP id 020A1100005 for ; Wed, 13 Nov 2024 06:03:23 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=InVgEUm1; spf=pass (imf14.hostedemail.com: domain of surenb@google.com designates 209.85.160.180 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=1731477708; 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=tkTrcrgQGR2r3+1USAH6qNDDRRqy2ByWWf6VKThfFFY=; b=1d2scaon8NRgcTczyKbj1WFRYonlwOrzat4EAHCq1K5LM8dOjYpVA5nWx6kqi6c7vEO01Z JjCrTbA0aSDu23fZYQKmwMMfS69Akw/TFXz8l8Rgg9bdEOgDvNw2CLLSUwZW8d5SSG9L8e 1Ev8xmzfY3ccUcbgyTpVbPZNTWYOWao= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731477708; a=rsa-sha256; cv=none; b=fgAFDGYaVC1yqhJLyBHabTPlEYC2Cm3chlGaQJhwYex73PYCmAC/5kJYiZtCxIia/6ACD+ 1TufnDU8ugdnSfCXLudZfxxMQJ0feYr/pMc5cWIckeBIGcFxIN4QF17TAwKGXzKCG03BjU IsQpJYUHTyx0PpjD+JE+8EJwAdmsiok= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=InVgEUm1; spf=pass (imf14.hostedemail.com: domain of surenb@google.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-460969c49f2so175411cf.0 for ; Tue, 12 Nov 2024 22:04:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1731477850; x=1732082650; 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=tkTrcrgQGR2r3+1USAH6qNDDRRqy2ByWWf6VKThfFFY=; b=InVgEUm13wUVfOpzRfEKw5dd6673jov7MC0a8tJStIXTNTQ650hxQ7/jhiMr5tUmXT IYcBPTrBV0EXhql84/8eXhiN+/qG3IZwPAl+wBDYaN4YNqzKcwIVtVaRhRK24A9jOKw1 hmLcblx3K3xsH+s0UP+1RWaKrNWw9IO2xAQ01lXhl/AmTz4M0pWR5xh6S3hq97Ch+jZE WUim5WGpPWLp9j3wjf50nlpDWotSgHWhei52RfWW1U0xctaOKz8GL8xr5g3Aeas9bAaZ 7c/YQ69l1KNQ0EqT8vSej/2Dw5O48Y9xiOK5lYsMOYUH03C63DoF3WXfHomgr8MkAESi R7HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731477850; x=1732082650; 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=tkTrcrgQGR2r3+1USAH6qNDDRRqy2ByWWf6VKThfFFY=; b=kMAoTlxf9TeR+/Jk02XTTpGbPidBWpKJYbofL5AL+UpBjAij7lTJd1m9tEBO9i59t7 mPnxfkQZqz/rOO9Qj4Ujk7aDEAKFO+Alxu6INYhlUhjjMV0Ri3BkA6zHS9bHL3E7urlp MYCLxE90lk5BEYuu6J/8Kyd+GdZ9gFr/UJ6pyW2lxERyZcbFQ2ACF86ROcy+ItNX1ZxW /OUnprYxY436s10m3NIcqSczAVlbdb4U58SdnHenelC461Ygx++u9srgVRejUV+vCs9y spq0MRPBfcsD+SeoLv1j1o8VE5fnPXZ5fC0Y6gAGU0QKXFVX/F3wbNGFwugHySsyuKfI NH3A== X-Forwarded-Encrypted: i=1; AJvYcCW/iyzUSxAX1QvP9PQKNYZh7pbT3jQCpHAGuspFGPwq+W3FZYKozZPx/BWkw9Kn5UgtcBZDVSfksw==@kvack.org X-Gm-Message-State: AOJu0YxC7AELCkH3Fcl5j3EgVoNGnbhHGmSc0WLhMLqIjLjpFe+/TynB OkxvjoZdhZgZDKDscvng4wNC9BkeJh85eVVG0nJ+lHdg0biKz/TEWiBPw4/+f+Gko1Ax/0m2355 wk38WM83ZApJ4djqiI4agLKdzWyug81yVHwe5 X-Gm-Gg: ASbGnctVwgrTyztgxr1plj/k3jiE3VdNgSemZCrjFjLN9tJJOIJNVhExWaB+FtD4QOZ juoElXMJmXoAyKT7K9y0bLRZzqZyDUxY= X-Google-Smtp-Source: AGHT+IHKadlPmr+WXI5vY40br0m0Jt+QE2K6y2TCMnr8S1pAbzEcnz6vIgPjIxOgjAUHu8gesnDyQ/X4px+cah5Jxeg= X-Received: by 2002:a05:622a:144b:b0:462:b6c6:8246 with SMTP id d75a77b69052e-4634bc104c6mr2313241cf.14.1731477850037; Tue, 12 Nov 2024 22:04:10 -0800 (PST) MIME-Version: 1.0 References: <20241112194635.444146-1-surenb@google.com> <20241112194635.444146-5-surenb@google.com> <6d0c5c2d-2963-489a-2376-8edaeb064de3@google.com> In-Reply-To: <6d0c5c2d-2963-489a-2376-8edaeb064de3@google.com> From: Suren Baghdasaryan Date: Tue, 12 Nov 2024 22:03:58 -0800 Message-ID: Subject: Re: [PATCH v2 4/5] mm: make vma cache SLAB_TYPESAFE_BY_RCU To: Hugh Dickins Cc: akpm@linux-foundation.org, willy@infradead.org, liam.howlett@oracle.com, lorenzo.stoakes@oracle.com, mhocko@suse.com, vbabka@suse.cz, 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, minchan@google.com, jannh@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, 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-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 020A1100005 X-Stat-Signature: fdswhpdua49kudd56tqrn8qi5n61xsdz X-HE-Tag: 1731477803-263406 X-HE-Meta: U2FsdGVkX197sxMO1HNdDupqypZmfOzPnFiYxeE7DcHcEIhvegRTwIapsa0OCR+K17G8hObIoR93MnyeNR2h2ZKi1zDh2QwLQQK6c6HTtXSFB9bHwDufGIrv0N+RyUcbj2GTomY4iWvvnWcWh0dt01cyZKDUALVNh3TsiqK67any0DZY0BG3HKPch+4HQHY84xGDJHDF8yEj8d38yypIVRObBUql9SeatrS1p2+UFtN/1OuuXCb4gh/e3OUpnc95yOmRa50w/DqdD8mDynw70/ItJe15+Tt4UMwj+zwvlkmBN8tp3fgQ3Xaon/TOrx6ezGg1EBSVDC0+OXPnBcc/OsZ2V0C0Ydjh1N4FheYMLFQ0BVJLCHXIxsV8ZMO1qIYJUGVbX05VO0jP+YBkmfj6AFV/DHH5plC12IARphfnapdShMrB/jovMRNxujRt3PwnOenkEnVXyzIs+mXGWTQniY70CKcfn+awQgWG+LQUMm2l/FTQvwcX45CYaot4cGhhd1VQz6TIJGaz738ICLX8YAjZ1EIOq5GfT2ydWQUwXWIsycsjN6BRreNN0GYGc+7bJb8thRc7rl0MW8jm5oelJC7TOcJX/t/d72kkmfeTrkKb1wQvTtiVNkjLDke5DtD12sJT6z6TXK0OUjLxF1UZq9UqHvUZWRiYNmjycHlfxAyTV1SxwCd5mlRVlCkqB3Yt++dSJMPW4oSwqb4KMQiwxzWf8vf7QMfjzXK6LedRz+8eRZTQRI7IezD94s7Vtlaq/gbe5SQbdbAUrYTznfy6zAaoOW4VwCPqx1KTcMjt0ONksx00x88o7O4FDxhC7Z4HpwA49LCptd5bBbhLlytOZbplzYN6bcgXGWOniKwFrjTAQVtCJWdPvhz9CUI0ltO0YRi+YcdNeIaEukqIuPp93H4IKU1YhWM5M9+/txG7CXy2tOUtno0Tm1biSn7iPNgqEpu/IUrLRGCX7dlF/CK cR1WMjCP SvuT7vga7QYvy4TH+Go5+q8k9BKGO+LCLcF7JaTee03N6Os9jMKkd2LwxhKiiQPdtbLewSKNLKOeLTPhxSbGgKQgci8zj/QLgd9BfcWHwqf0zOesI9DuRMz/tn9i2Y9hiS8MNo9Ybln8SMnlGGgbWGjdNJT/ZiUaLiOCS8p9hfORft31ZGV22H/3qlabjpTFCbGHFRm41v5CA5Jenxj2p8Ydwp7jkyFOVWX0BwBK9wNHrY2oOjMn9i2+Hbv4G/nZ8GVCb9v6roztVZneY8UY6XpXpnLCtFBlsNBp6pMPHJU8JCBHsDnnvUVPzaG2rv9ESNUjt 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 Tue, Nov 12, 2024 at 9:08=E2=80=AFPM Hugh Dickins wro= te: > > On Tue, 12 Nov 2024, Suren Baghdasaryan wrote: > > > > Thinking about this some more, I don't think this works. I'm relying > > on vma_start_read() to stabilize the vma, however the lock I'm taking > > is part of the vma which can be reused from under us. So, the lock I'm > > taking might be reinitialized after I take the lock... > > I need to figure out a way to stabilize the vma in some other manner > > before taking this lock. > > (I'm not paying attention and following the patches, I just happened > to notice this remark: forgive me if I'm out of context and have > misunderstood, but hope this might help:) > > But this is exactly the problem SLAB_TYPESAFE_BY_RCU was invented for. > You just have to be careful that the locks are initialized only when the > slab is first created (allocated from buddy), not reinitialized whenever > a new object is allocated from that slab. Hi Hugh! I'm looking into SLAB_TYPESAFE_BY_RCU implementation and trying to figure out if initializing the lock in the ctor() of the cache as mentioned in the comment here: https://elixir.bootlin.com/linux/v6.12-rc7/source/include/linux/slab.h#L127 would help my case. I assume that's what you are hinting here? > > Hugh