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 8FD83CF3942 for ; Thu, 19 Sep 2024 13:57:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B8B756B008A; Thu, 19 Sep 2024 09:57:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B3BB06B008C; Thu, 19 Sep 2024 09:57:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B41E6B0092; Thu, 19 Sep 2024 09:57:40 -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 7A6466B008A for ; Thu, 19 Sep 2024 09:57:40 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 017CAA0D79 for ; Thu, 19 Sep 2024 13:57:39 +0000 (UTC) X-FDA: 82581640680.07.D0F50C9 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by imf21.hostedemail.com (Postfix) with ESMTP id 195441C0007 for ; Thu, 19 Sep 2024 13:57:37 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EQwsXmnX; spf=pass (imf21.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.210.172 as permitted sender) smtp.mailfrom=mmpgouride@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726754200; a=rsa-sha256; cv=none; b=0VIFErX/H9G5JQibMXDiwrr+o70BidqgVbiVwIrnlx0onqMLMpWG2+zG+DiSvq6ZQpVTZK spEuJzoM71Dxh9RYWssSqac1jbN7OGOWusTPSStE+m+DoGsZcBUCyNd7JxejvsMIkR2TKo HlOiXFGOhRBw/G3wvffyHEJ+OR/5F1c= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EQwsXmnX; spf=pass (imf21.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.210.172 as permitted sender) smtp.mailfrom=mmpgouride@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726754200; 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=W9KoiB0YsZBX4kdWY2koiL+vhQxEK5DgJarh6ifR10c=; b=tl3sRWAEeQudWnlsVJ5racc8lepSemy9nIcodl/l5Dazgx4yH4YcGwFnEwyOhCpJlUBcwD Lzcjn8bFAQc9kic+UGy3FsoFcMnuQeo+sj9QFHv6I+QM5xTtYq8AAfrW7TXpDvm+1sraYi 4jJ2dX5S76oKsWQYt/BUPq/3VS3zTuQ= Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-7191fb54147so647687b3a.2 for ; Thu, 19 Sep 2024 06:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726754257; x=1727359057; 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=W9KoiB0YsZBX4kdWY2koiL+vhQxEK5DgJarh6ifR10c=; b=EQwsXmnXz2kqzcUCN3CId8zbjhqLqkxthwW/6yjG+lzb7cMCtFDqsP0WUswbFk5+n4 9GTL4SHjTEapV10amrW3d2Ia8JLtMjeyGr3VJkndUAus4Y1CERxGYJBLfoB4S8Y32gZ/ PoqVKCADffkLNg0ugaWPacgdc1WU60uPTHIMS0Qs043O8r2dZIDnNw+DrZS/Puu1XaBJ bzD156AVRNch1sRGTONLGZsGreeks1hIY85vroWftdO7z2Cg0VXLOl5LR2v0ugfb8r1D 6rPylEfX4ZsSJpunH6XNiRd4qOlq/Q+cKHupz0cQaezmlaUFoYYqFa3o5VjQHvSNwDX2 68mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726754257; x=1727359057; 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=W9KoiB0YsZBX4kdWY2koiL+vhQxEK5DgJarh6ifR10c=; b=h9MjpAEnOgWKtseBx8CJaFAzWQoByja7Tpc0Euu3Dj30qGnOUOvVxLfupK+o0C2NAm 95mvTERpsSkz8avXyPKtOJbYaD/akhL69HGmw2H4YYSEVA6Q1d9PHArE1ZWf1owZ6Y2f g2b7wBHY/6wGIcGcxYJflq2/PWPaCQDy1UQj6TVARToX6FxXpZosuFjwaCwXzoLRAg6y BgExp/P6mIoNkDk47bQdUD4LloRHcNz3S9LWelu5G/53O1JPWoK20KmcMSuRWje/cGGT CUMSPW8RI3hAXs/q7+FwNM1SOcd7v5mnXCQKs1eW9lUQulk17OFC3F9T5FOS2TZonqq2 NaQQ== X-Forwarded-Encrypted: i=1; AJvYcCUOr+k+8e3mEOqltD1ThrAu/CwDGjKiOn4r93SjN+zNSS59ILOyMnUWmTLB85u25RDAh5xp0Z6ybw==@kvack.org X-Gm-Message-State: AOJu0YyPrhN5pWjkjbqkF4DU9jTOkivUehO8/2emQk8gwglQ5tS3Fb7S ll76BIik5Q36raC6qQYI84an08jh/0o1WQ454crdCLsSDZcCL2rO X-Google-Smtp-Source: AGHT+IG3NM9cbEsGODVNJC/nw53fZr59xEmoESCbE/ZFVMlqAxM2UadkXcrIOGgUj+nimzv9M+wsaw== X-Received: by 2002:aa7:8895:0:b0:717:8deb:c195 with SMTP id d2e1a72fcca58-719261eca18mr41957713b3a.21.1726754256588; Thu, 19 Sep 2024 06:57:36 -0700 (PDT) Received: from smtpclient.apple ([2402:d0c0:11:86::1]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71944bc543dsm8267246b3a.204.2024.09.19.06.57.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Sep 2024 06:57:36 -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: Thu, 19 Sep 2024 21:57:12 +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: 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-Stat-Signature: cpbqos5on9ztuk6et5x8rhwiyq4onaay X-Rspamd-Queue-Id: 195441C0007 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1726754257-219232 X-HE-Meta: U2FsdGVkX18UF6+IRSVMGHFOpWDcLtjZkEkIrogKpkH6C13U/7lNFs5tLPiyuzdWUBO+z1ZlvUimBnnFZJ5exlWPrhWgmt95ayMgocOd3lskbzSEn0qhrvs867g3ysXm+KTVvUWWtqXy3ZwKKufM3fef7sOMZ5FMQUoxwnwbERhPn+f+3kwPcFKXTj91HlGwwDegWC16Dt4MAWUoK6srT05rUmAyeArw0vgNLH3Lu7iQiv83y5QNB1PEnHllebGmjfuQ4rwX+TWWepzUnNNDhgufmtMAw85hUcZQYwEP/rjZmddZJ1rX1iBKQfQj7zWVx3LmLlavck0VDSBT/TI+8DxEF2I7F9p+ToWsPToCirr0D9WN8QbhuZYrSwqRQOIQiPH5ioxar4N402HkM/KH0TrDCKEaGHFal1l8WcpiSZA+8sZA0MbmxpcvEglqwSjw/aX7ZdfTeeHBBrDpkiRE3y91LiVpy9YmHS/ZApxbnWS/MxawtVJGXO8NXftLsBfsqoup/XWlXS5lAbLcp75m6MX1wiRpZRaRCdARcY4zrVisOHcaC6iRmzvKYpng5MkAL+viUIbbogjvNg+eY8RNH7E+i5JpCvt3mjEupPeaidunYknwVwhPf44Yn7K0puqPcZv965CsxKLEscGS/zQwu1UHdLL/dWphtQCEPEB/3ayz+n+RLgZYWylwqyTaEiw+4O1uj7gKByYCjEaDlDrIJzYwYsz4mgr2t+OTH5YKWdI9F4OQ022/pixwMgiRMzOeMrYauXDRH55bnZlzPptvDGKbTNzL/a76c5GKLyNdK6X+GRKNo8mVrYNXmhP4Gb7odI1gQJiOKEFIEafxj3fXsC5hx24kEm6/PqmDozebzLcRc9VRLYQH+dy5n/1ntA78x5iNm//pQW9DI3xb7dqpPIsWng3IQeivOqHu/x3PCu4/uOtpg/kuuAwF6Acrbz4Qd0ii74PdvYNuKMmnEmD sTwFEXq4 8ohJcJ8e7ENsIHvdaaaizU8qR79Keis9ZDrWHFh5fIVYiQduKqROsvB3neZw4ALXzOaAO2vOQdd/8mOLMzPVUH1brpfdKwJQKWBKA2reTmhgVA1RXM2/mXnRBdYJ/p74lwjWXL5+0k+MTp2mT1+A3YIfIWf7a9TdQ8M0YrsrDPU7IsWJz8UzGR2b0Z6612LwmsoEjvHWk2BEVFVWzd6BoeEQ6aC38qsUVeA9MTWo2/ouUde3zBwEOqZzixpxYjXWQnB7eYI3+yWeph+fml7LuocMdoHfNEexUflu8qlUbboOSmV13/xyj8i2Z+QxG78psC7lLDN9L2Wmfjz+5/xF8T452gU49XWXNxMckrtO7LUqUDicBl9iMl/Tc93iuqd6/Fu0DsoIU0IVbgpOSWlESCUd7Zp+90c94PnihyR0YF1Y+QT4jWEq/Nhss70xjIOoPS6GdF0AMsbpkPbSkatym88A4OJyCGRtB88Dhux+u30lL+OfGdlHW8xAXkKlTXBUFCGxdHpK2A2A+9E5FT5IuDoPeDr5o0tLh9bOcAnp5rE/gnpP+RwKyk8VRPQ== 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); > } It seems like that two different hazptr_context can=E2=80=99t be used to = protect the same pointer? Otherwise the following can happen? thread1 thread2 = thread3(worker) thread4 hazptr_tryprotect(hzp1, ptr1) hazptr_tryprotect(hzp2, ptr1)=20 = add ptr1 to tree hazptr_clear(hzp1)=20 hazptr_tryprotect(hzp1, ptr2)=20 = delete ptr1 from tree unpub ptr1 = call_hazptr(ptr1) = oops: invoke = ptr1's callback Or am I missing something? >=20 > Regards, > Boqun >=20 >> I'm not so sure... >>=20 >> Thanks >> Lai