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 321EFCF3959 for ; Thu, 19 Sep 2024 16:10:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B030E6B0096; Thu, 19 Sep 2024 12:10:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A8BFF6B0098; Thu, 19 Sep 2024 12:10:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92CD16B0099; Thu, 19 Sep 2024 12:10:26 -0400 (EDT) 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 7512F6B0096 for ; Thu, 19 Sep 2024 12:10:26 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0B368160CFB for ; Thu, 19 Sep 2024 16:10:26 +0000 (UTC) X-FDA: 82581975252.01.5C3E320 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf04.hostedemail.com (Postfix) with ESMTP id 0EE2840022 for ; Thu, 19 Sep 2024 16:10:23 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GcarGsS1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=mmpgouride@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726762140; a=rsa-sha256; cv=none; b=k6yfVnZWJ0OwxiZYvqQuZ/WE1nEU17mAoNUppv5qUoXzP9+YLY/HqVWM6t5uEkEMAPUy2k nAYvR/opYF303BC3DEUmdoUhYT37+M+0CLRbh0ETU/DKK0hm7GqlU5ldUboi03+8xlfvXz BtDqhpyUXhliOQYsfFfZEkvC7akYlys= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GcarGsS1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=mmpgouride@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726762140; 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=PY/fGPKseiN5XtuGoO/dNcX3n8cZ54goexwrvXf3OMI=; b=CrvbgTIlw6OYOw9CGxEJM8Y9ay1jl2TICgNjhIETv1BDilmW5Y3F4uvtc+smfzSBj/hLxY 5RMNf77uFIvdItQ1b2J5CvvumGvr/b+BsKofUSION2y/LUB8ngoDBDi2d5hUB2A2OOz3PA SFEd6X+tYDkJrTqf6Lbcg/Q5gn5N4CA= Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-2059112f0a7so10886545ad.3 for ; Thu, 19 Sep 2024 09:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726762223; x=1727367023; darn=kvack.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PY/fGPKseiN5XtuGoO/dNcX3n8cZ54goexwrvXf3OMI=; b=GcarGsS1bdrMpoH6ev16l6nzXkRlfjcZDM+RRsT09t57EjavEKOXBLB6maosnGf7RI YKeJb/pwasLyVdVIRDR/rHbNUsJ8/OyO3JYK+4x7paqRpHw/mTf0a7vLINHkMIJgPwFg LfDzCeRyoba36KDDAPPkQesTKWqtER3x2bkq16Gy+Piq8qjo0VPfG1N9RGz9uyEgMJ3f qDWTexjl2b3Dq9PrElA7v6ZKP96J8qZ/o4TVCx+Z/A67zVE/p/3JZYOM8p0a6+kmw1tD 1jopcP+zXxvNAsk8gEsRezJLK/V1clqxPNv8SabnWH/jpDtN+Q2kRNo704lvA9YjEDxP rCpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726762223; x=1727367023; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PY/fGPKseiN5XtuGoO/dNcX3n8cZ54goexwrvXf3OMI=; b=wuGaKJUt/r2EWzD7uWb7bgm3+Roojl+Hp1s3jNrrUSvd5T0KBzHz3X8f1I6brj0+U5 UdjmT347F4teIixLMM2e0fpUBMJadfLI/tcktQqLazY/2g30l18f411avbYAG++qra/4 pDAVbr+1czw/Cn7e188wU5EbThvalIiQwYg+37e7FEBBp4W2emzVEqStFVz5OaCbFjW8 jHPjYxNtTBu2U8iXtvAbFroLAE6EgCeIYNOA7KYONcUTPBoYK+VWEU7pZkGhgB8R5Up0 kHa/Us7H8jxTXKuOywrvyU9TqR8iaU3QrBoz4Ylpm9KpFrW+rd7owihLaN+szo9aZslf nMcQ== X-Forwarded-Encrypted: i=1; AJvYcCX1bJd9ZLKVJhJNopO02ecObeDPvE460QSVzPhn5ZpkoAnAcy+Vy/ePuvlKc+xUqpC92NjawWvoMA==@kvack.org X-Gm-Message-State: AOJu0YxAgmoO8NKqb0bpIglbV7PFMd9iKK41ZL8ucCDS2vJbBjIHGIfz NXkKKGfxa10tI1HxfzCiYr1IxWtWyMAFndGcVf55jP2jkS0TXaTA X-Google-Smtp-Source: AGHT+IE63MOrtSDNRE1puuTOcxVEkzUx9edmw7szWrDYdYgkMNwLAGdFxq+KU06AHJcAn9dSKTtEfw== X-Received: by 2002:a17:902:ea09:b0:206:9399:5dd7 with SMTP id d9443c01a7336-20782c16174mr330479015ad.56.1726762222437; Thu, 19 Sep 2024 09:10:22 -0700 (PDT) Received: from smtpclient.apple ([2402:d0c0:11:86::1]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-207946d17fbsm81702445ad.152.2024.09.19.09.10.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Sep 2024 09:10:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers From: Alan Huang In-Reply-To: Date: Fri, 20 Sep 2024 00:10:03 +0800 Cc: Lai Jiangshan , LKML , RCU , linux-mm@kvack.org, lkmm@lists.linux.dev, "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , "Uladzislau Rezki (Sony)" , Steven Rostedt , Mathieu Desnoyers , Zqiang , Peter Zijlstra , Ingo Molnar , Will Deacon , Waiman Long , Mark Rutland , Thomas Gleixner , Kent Overstreet , Linus Torvalds , Vlastimil Babka , maged.michael@gmail.com, Neeraj upadhyay Content-Transfer-Encoding: quoted-printable Message-Id: <28F2EAFF-1DF6-41EC-9DFC-3B437D67D840@gmail.com> References: <20240917143402.930114-1-boqun.feng@gmail.com> <20240917143402.930114-2-boqun.feng@gmail.com> To: Boqun Feng X-Mailer: Apple Mail (2.3776.700.51) X-Rspamd-Queue-Id: 0EE2840022 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 9uwhuehb1edwm58p1yetwxfcndxhfb7s X-HE-Tag: 1726762223-406952 X-HE-Meta: U2FsdGVkX1/C6NnIHT3lMdXYOC1RtiRMjR3x6FXP4Wd7jEf7mQH63Bi48L1Ch0p8eV0kjCGSy18eBKCvhi3BkMVz7dRbWkk/sqs3Ogq7s9k6V5baeqKd+nWWjQ1g2KL5gUoABS/WhPhW3OOyuClsKrCobzhJKDS9ALalhcnpmYVvrQwlwn1dHmWULnqGjUHM1SHWb0cx+HNhFt2nnI6/cWRyg+GUn4vR5uQOZGBY7zRFJNUEyN/SBx0RT0p4hm5byngkWRKgxDjLYOPNX55Ze9zbU2Tj4FIv92eO3J13NquQy1aGCVv7fyQKXp7592j2rAXFjUlgihBPO707wNUu1Brl1Phqc2lOiL37ECYILuDHRAtNW7mgiJRHZRAmh4oDXQaT8faYw+4ZqNRmcouREKblE2W8MsGHXzo0z9AII4+XsntACJtMDBMCiePQwKiz4P2xsDBDiRsvisJMC76tRhHzs1quReNR7KC8Xk3u7eXa9oeSSF2s4txDBuHthwkysdbtLMh3ZGkGG6QmC70lDDittAhazKgbm3ueEfGY8Vtzd9iolgzNSeTfDgpLyAXo0yFOInzmHYtfMrkWYsXEnzA0EWtg6gPKMRObY0IAYniVHXeyH1nzFzz6y+m1Np2C9Wojroc7FNBWLSi6WkYep7hG/AicPMXod4Zc50lhqQRC5mmfgPGVOZ/da/unqt0+A5CHSfyFjgP7lRuO5h3r0tBN4gN6pzI+SS1FoTlspu3srN+BoLWMz2XoP7FZdeWJeg8xynZPcsnJ57c0PU8SDefnxiNtCgGus9YUgJROVjWH8xacwbTLmtBA3jeoALFck7YZQ+XmLttRE/zr2cz9BD8CIsmBIl/X6HT9HoQ8ejAPFUZrloM23bWA77WnbhbZv6H5rDUHQ/v52kR2oZg67p489o/Wv4esQmxXqu6rhGe+kMrbABOeGzMYUqlJzBR7E8bXmBWWGPDtZHtj/xa 8q1Sxewf KJl5Vv4+74NxKwjYlmwCr/kN+x1wi2xmJKeggIOyQG2yIpXGcR1X70UKU+mhqDDiyxjhYZujuRFGFdEcCIYrmE9b2h36YubMzw8M9wLUysR9NFdHhSF3799FhWNE9jIihk1U/jAPVUH22/TRnPkrNaGettu6PEao8U38kvLf9jzRKbQqMrP9kD/nCmWkj+Rv16ICdxj5MZOc6kpIYaF03KmyT5Zj48kHWCoJvBfxoMLza6XsqeJye8jVyCxzw/4z5GP+GUTmX1QPfmUjCCPqmXtlpkIhQg08+6kTvB4TZ1WhRYrtQDH7IHYk9axlAMqORsYPFNkDVuRRfUSRQxVmzaTVu5M8JhwU9uyZ6g+3Fi0G5wO3hyW/pqv0vF8qNOZuxuSNcMaK22CmEuWnbqGn6eLbNcAlZLz7oDgfnAuE1HdZzyd9hbxaW58AeGQKE2b3Rr3D+Ua545OPrSf9+7tuioWxNRsX4WHxEZYGWfVMEAHuycloOm5McMQJXf8XULZE74zyqaQ6ko3d3XUo6b93Vetd9otgU+vCpdxa0/Rww+PgUO9wRFtlHQxJYZw== 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: 2024=E5=B9=B49=E6=9C=8819=E6=97=A5 15:10=EF=BC=8CBoqun Feng = wrote=EF=BC=9A >=20 > On Thu, Sep 19, 2024 at 02:39:13PM +0800, Lai Jiangshan wrote: >> On Tue, Sep 17, 2024 at 10:34=E2=80=AFPM Boqun Feng = wrote: >>=20 >>> +static void hazptr_context_snap_readers_locked(struct = hazptr_reader_tree *tree, >>> + struct hazptr_context = *hzcp) >>> +{ >>> + lockdep_assert_held(hzcp->lock); >>> + >>> + for (int i =3D 0; i < HAZPTR_SLOT_PER_CTX; i++) { >>> + /* >>> + * Pairs with smp_store_release() in = hazptr_{clear,free}(). >>> + * >>> + * Ensure >>> + * >>> + * >>> + * >>> + * [access protected pointers] >>> + * hazptr_clear(); >>> + * smp_store_release() >>> + * // in reader scan. >>> + * smp_load_acquire(); // is = null or unused. >>> + * [run callbacks] // all = accesses from >>> + * // reader = must be >>> + * // observed. >>> + */ >>> + hazptr_t val =3D smp_load_acquire(&hzcp->slots[i]); >>> + >>> + if (!is_null_or_unused(val)) { >>> + struct hazptr_slot_snap *snap =3D = &hzcp->snaps[i]; >>> + >>> + // Already in the tree, need to remove = first. >>> + if (!is_null_or_unused(snap->slot)) { >>> + reader_del(tree, snap); >>> + } >>> + snap->slot =3D val; >>> + reader_add(tree, snap); >>> + } >>> + } >>> +} >>=20 >> Hello >>=20 >> I'm curious about whether there are any possible memory leaks here. >>=20 >> It seems that call_hazptr() never frees the memory until the slot is >> set to another valid value. >>=20 >> In the code here, the snap is not deleted when hzcp->snaps[i] is = null/unused >> and snap->slot is not which I think it should be. >>=20 >> And it can cause unneeded deletion and addition of the snap if the = slot >> value is unchanged. >>=20 >=20 > I think you're right. (Although the node will be eventually deleted at > cleanup_hazptr_context(), however there could be a long-live > hazptr_context). It should be: >=20 > hazptr_t val =3D smp_load_acquire(&hzcp->slots[i]); > struct hazptr_slot_snap *snap =3D &hzcp->snaps[i]; >=20 > if (val !=3D snap->slot) { // val changed, need to update the tree = node. > // Already in the tree, need to remove first. > if (!is_null_or_unused(snap->slot)) { > reader_del(tree, snap); > } >=20 > // use the latest snapshot. > snap->slot =3D val; >=20 > // Add it into tree if there is a reader > if (!is_null_or_unused(val)) > reader_add(tree, snap); > } Even using the same context, if two slots are used to protect the same = pointer, let it be ptr1, then if the second slot is reused for ptr2, ptr1=E2=80=99s callback will = be invoked even the first slot still has the ptr1. The original patch also has this problem. >=20 > Regards, > Boqun >=20 >> I'm not so sure... >>=20 >> Thanks >> Lai