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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97736C636D6 for ; Fri, 3 Feb 2023 07:43:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232055AbjBCHna (ORCPT ); Fri, 3 Feb 2023 02:43:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60148 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230496AbjBCHn3 (ORCPT ); Fri, 3 Feb 2023 02:43:29 -0500 Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DA1E1B449; Thu, 2 Feb 2023 23:43:27 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id cr22so4624018qtb.10; Thu, 02 Feb 2023 23:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=oFf9KYeQPAcUoBOf/mOzVaePC0gDGny8p7rFF3Zsr2g=; b=pXigfP4rXkLLFuB8HyAn7teR52dw/IXzeQAqr2kDRPKVxbAGDlIBy4mnnEBEo3ew7c UURLHoFH9pMI6jJLTpK41RMTN64erE6mvRbxJ0KvZyNAxlZlsqozC6YefqtD7kEiTfnv p2zvNigTdXQwcDtxblEyCCbE4EyzfP/e+C6xgOi4pt3/JF9ZD2odO4hMwBeArjoyi3hQ zdjK+PLLQS0hPP1mFhfHObr4Y1aUUHD/O5yN2rlWsc6SDgZ6YHAEXTWwg1amSK6j/f30 j6z66KkRscFtO9wDh6L+9xIUGGSd0oMh/fgVBkaK0W6wmOC2C0Dc4J+ltygqwcAffUI0 cvYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oFf9KYeQPAcUoBOf/mOzVaePC0gDGny8p7rFF3Zsr2g=; b=yXOYrfkjKd8Yze1oM4Z0tRK6iS68jluGeLFdxcoKYZqDRuvJ2qFspRiqPr0HbIyuJ6 r6Wz5Kpvoc2I9lWetOfYG4UuA5CX4cdzFXZLJpaUBqolMKgbFt8oqTtOJf3idn5bBInT WFqdfMN+ThpdWXm3lMjxfxIKyNxnt1nMfr+d7Zya5BzoqayFwYcSJneTI1NZ+bkqgf6g 6rFq/qo91LHOy+100LfD3KAN9JU22BRkSkzJmE+af8wkAAar4zgzlNpjomFZsikEmlrX WlOGZ3xci+Nq+Fh4z8KPqT+iMKyWkUkdC/RImyud1Wem3laVKna6a1sDFEBZuKqNZmN6 +V/g== X-Gm-Message-State: AO0yUKVyiP9uUyJnwj8d1K8Fwo+dXXItGFWL4VSET1uJqC5OwrMfZ6P4 3zhqZrwS0+OOYE+N8wEQY5o= X-Google-Smtp-Source: AK7set8Lnh4m4u9mvYRGiuMz5HH4jWhWZM5oIcLdp6MGPmhHVv4IfvylZOY/1apoK5yOLAYa+dVnYg== X-Received: by 2002:ac8:5e4f:0:b0:3b9:a4c4:ca09 with SMTP id i15-20020ac85e4f000000b003b9a4c4ca09mr18692642qtx.10.1675410206950; Thu, 02 Feb 2023 23:43:26 -0800 (PST) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com. [66.111.4.228]) by smtp.gmail.com with ESMTPSA id d136-20020a37688e000000b006fa4ac86bfbsm1342844qkc.55.2023.02.02.23.43.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Feb 2023 23:43:26 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id D5F6C27C0054; Fri, 3 Feb 2023 02:43:25 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 03 Feb 2023 02:43:25 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefledguddtlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeeuohhq uhhnucfhvghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrf grthhtvghrnhephedugfduffffteeutddvheeuveelvdfhleelieevtdeguefhgeeuveei udffiedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epsghoqhhunhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqieelvdeghedt ieegqddujeejkeehheehvddqsghoqhhunhdrfhgvnhhgpeepghhmrghilhdrtghomhesfh higihmvgdrnhgrmhgv X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 3 Feb 2023 02:43:25 -0500 (EST) Date: Thu, 2 Feb 2023 23:43:23 -0800 From: Boqun Feng To: Greg KH Cc: Miguel Ojeda , Gary Guo , Peter Zijlstra , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Will Deacon , Mark Rutland , Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Vincenzo Palazzo Subject: Re: [RFC 2/5] rust: sync: Arc: Introduces ArcInner::count() Message-ID: References: <20230202142153.352ba479.gary@garyguo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: rust-for-linux@vger.kernel.org On Fri, Feb 03, 2023 at 08:38:25AM +0100, Greg KH wrote: > On Thu, Feb 02, 2023 at 11:25:08PM -0800, Boqun Feng wrote: > > On Fri, Feb 03, 2023 at 06:22:15AM +0100, Greg KH wrote: > > > On Thu, Feb 02, 2023 at 10:47:12PM +0100, Miguel Ojeda wrote: > > > > On Thu, Feb 2, 2023 at 5:52 PM Boqun Feng wrote: > > > > > > > > > > As I said, I'm open to remove the printing of the refcount, and if you > > > > > and Peter think maybe it's OK to do that after the explanation above, > > > > > > > > Perhaps part of the confusion came from the overloaded "safe" term. > > > > > > > > When Gary and Boqun used the term "safe", they meant it in the Rust > > > > sense, i.e. calling the method will not allow to introduce undefined > > > > behavior. While I think Peter and Greg are using the term to mean > > > > something different. > > > > > > Yes, I mean it in a "this is not giving you the value you think you are > > > getting and you can not rely on it for anything at all as it is going to > > > be incorrect" meaning. > > > > > > Which in kernel code means "this is not something you should do". > > > > > > > Now what really confuses me is why kref_read() is safe.. > > It isn't, and I hate it and it should be removed from the kernel > entirely. But the scsi and drm developers seem to insist that "their > locking model ensures it will be safe to use" and I lost that argument > :( > > > or how this is different than kref_read(). > > It isn't, but again, I don't like that and do not agree it should be > used as it is almost always a sign that the logic in the code is > incorrect. > > > Needless to say that ArcInner::count() can guarantee not reading 0 > > How? Because you have an implicit reference on it already? If so, then > why does reading from it matter at all, as if you have a reference, you > know it isn't 0, and that's all that you can really care about. You > don't care about any number other than 0 for a reference count, as by > definition, that's what a reference count does :) > Fair enough! > > (because of the type invariants) but kref_read() cannot.. > > I totally agree with you. Let's not mirror bad decisions of legacy > subsystems in the kernel written in C with new designs in Rust please. > Roger that, will remove this in the next version ;-) Regards, Boqun > thanks, > > greg k-h