Received: by 2002:a05:6358:53a8:b0:117:f937:c515 with SMTP id z40csp3821673rwe; Mon, 17 Apr 2023 04:12:11 -0700 (PDT) X-Google-Smtp-Source: AKy350ZuyVKmsFEmI32+ncwaqGGbLo2DxuQB4rRgl2EetSSqVTJ2TikN98QnGRWB7IsYDXDs9taN X-Received: by 2002:a17:902:e54f:b0:19c:a9b8:4349 with SMTP id n15-20020a170902e54f00b0019ca9b84349mr16253371plf.32.1681729931605; Mon, 17 Apr 2023 04:12:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681729931; cv=none; d=google.com; s=arc-20160816; b=XoHm4PFWngtRJEAHRq1TBGZ0yW8nzMegg/CAAiGk+VJYvGkyW7G4z3SbbOiH2SHKDK apW1UUMJXkv9JBNplI6J5ZaID3WqbloSSji17IkBBdR9isWqi/22ALV7mc5R6j5zfePd IZ3Xn0PWg3bH6QbWNW+JG2mkdU4iM0+D7AjsxYlkPdoAIdhsjyY104lBMRPxKARCiqlP 87Q5a/BVnHh4wJP9JzI2SNF2tG2+sWK+YldM9IKkDn14+17CZcKyr0IeGJEleQPPbSQA bWWrypcjcVbvTwioByfJo59OekXDPjPFOtFO9QDQIHwghx3KfOQvt28mb0wgrV9qMWsS NVBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:dkim-signature:dkim-signature; bh=06x+K+qEGfBWa+nBU0/XoNWbB2gYx2EZL8IXlmuFUqM=; b=sX3xN5tG8Wli7d+crSaPv2O3cD3cDTFtv1arm4EzagbqThG0QU2jfMJTFduQye7Ic+ yZaAIGV27pEJBqPO9qROpUuG4i4X1L9PJUganr0c5uDrYAwxwoDmxeC4hqd2YIXetQRE oFCTg0/964Q3FdRQ9cd+jRS5r3Eo76BwhlhmUdUNB+4hEphQdt+mIUv5X9H8r0k9r7oC EvvHLTphitvDZRzoU1u4A0qB57pyE0u/n4nPhHR5RgsXJnvQmnyHdrTL5I2/ho3oX/+b eaoEIYcq0PCu+Kn4FOo/abKKzHwrDSSEw8krocjeoI1LF2rJ8u/qbdXbj69SykO7RiUi PE4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=COW+9s2V; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hk2-20020a17090b224200b0023750b695e1si103114pjb.156.2023.04.17.04.11.59; Mon, 17 Apr 2023 04:12:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=COW+9s2V; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229573AbjDQLIb (ORCPT + 99 others); Mon, 17 Apr 2023 07:08:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35316 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229554AbjDQLIa (ORCPT ); Mon, 17 Apr 2023 07:08:30 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0AEEC10D3 for ; Mon, 17 Apr 2023 04:07:31 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 5D9931F749; Mon, 17 Apr 2023 11:05:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1681729541; h=from:from:reply-to: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; bh=06x+K+qEGfBWa+nBU0/XoNWbB2gYx2EZL8IXlmuFUqM=; b=COW+9s2VXZkV8/jn1ThdDLAyMwQJ0ocv9VeWZi5xuVChVexb3Qh8ZTBIiPUs0hIbmhzCWZ RPhWlsG7+x4MuHb252ImXQHQZPA/pkuTsGIRe//3frw7ptJPEBaNvFEpn7AjP8DrRcJCLY qvYWRoVmAzXsQNpqm8H7stf+BBxqDwo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1681729541; h=from:from:reply-to: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; bh=06x+K+qEGfBWa+nBU0/XoNWbB2gYx2EZL8IXlmuFUqM=; b=09I3ZDMZvSsWvPtIVWL71LdC5t61NhDSuFrK9CiRWpjWyI/LYDb1vsB+RAmuhPyFZdoALV bDh3m348Ja6awAAQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 3EFF113319; Mon, 17 Apr 2023 11:05:41 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id TjzHDgUoPWRwGwAAMHmgww (envelope-from ); Mon, 17 Apr 2023 11:05:41 +0000 Message-ID: Date: Mon, 17 Apr 2023 13:05:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v2 2/2] mm/slab: break up RCU readers on SLAB_TYPESAFE_BY_RCU example code To: SeongJae Park , akpm@linux-foundation.org Cc: willy@infradead.org, paulmck@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20230415033159.4249-1-sj@kernel.org> <20230415033159.4249-3-sj@kernel.org> Content-Language: en-US From: Vlastimil Babka In-Reply-To: <20230415033159.4249-3-sj@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/15/23 05:31, SeongJae Park wrote: > The SLAB_TYPESAFE_BY_RCU example code snippet is having not tiny RCU Since "tiny RCU" means something quite specific in the RCU world, it can be confusing to read it in this sense. We could say e.g. "... snippet uses a single RCU read-side critical section for retries"? > read-side critical section. 'Documentation/RCU/rculist_nulls.rst' has > similar example code snippet, and commit da82af04352b ("doc: Update and > wordsmith rculist_nulls.rst") has broken it. "has broken it" has quite different meaning than "has broken it up" :) I guess we could just add the "up", unless someone has an even better wording. > Apply the change to > SLAB_TYPESAFE_BY_RCU example code snippet, too. > > Signed-off-by: SeongJae Park > --- > include/linux/slab.h | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/include/linux/slab.h b/include/linux/slab.h > index b18e56c6f06c..6acf1b7c6551 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -53,16 +53,18 @@ > * stays valid, the trick to using this is relying on an independent > * object validation pass. Something like: > * > + * begin: > * rcu_read_lock(); > - * again: > * obj = lockless_lookup(key); > * if (obj) { > * if (!try_get_ref(obj)) // might fail for free objects > - * goto again; > + * rcu_read_unlock(); > + * goto begin; > * > * if (obj->key != key) { // not the object we expected > * put_ref(obj); > - * goto again; > + * rcu_read_unlock(); > + * goto begin; > * } > * } > * rcu_read_unlock();