From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9A178168 for ; Wed, 7 Jul 2021 20:58:57 +0000 (UTC) Received: by mail-io1-f48.google.com with SMTP id l18so454871iow.4 for ; Wed, 07 Jul 2021 13:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gHFc4+0zFtEDK9o/0UC9ep6gO0PlVmpeiAjlwnNkVo8=; b=J1M4d2gXwavu4eE9ppE36TWhykhdZkl8ECNafjHg+5xuJQB7xzuzGWVQQObfYhC1kB 2zH90hhr0TBcdcN/eH4Jyx6/Bj8XPeZIPfpOCu27jQN2p0rqYfbG7LC6sKyx+NYSgpLG 4eo8gIDkXVZsU9z7WtG1RAhYm5rkSplg9X9H7dKAS1NueJxwktYRX2/yZrce8M7Lkit2 Yrs3X7DCxy1ywA00FIZ8G1hjQKrASOUuC176Z8aJ+rJZHmaWl19swQxzJ1aDCwgY4QKM tbJgJRc6DlAdIOBN9GOIj/M3k9QjHUn5Obj3MDSdNNbAleOdpvngClBvije9M7sajbOE OulA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gHFc4+0zFtEDK9o/0UC9ep6gO0PlVmpeiAjlwnNkVo8=; b=aq6VF/EqeMCPJEvRRUKdzUs0FE/Z/CLVMsl0GuReoUC15Ka4HBqWL9Ejt8KGA5MOy0 CTfTZOjd/XkVzlaZMsdwO81Dkvb/YJz4107sxFFPV557ttT+v/kFmTvYxbxjx/ezU1A/ od5GN9ywoIOfIsB3fAKs+Y4ojIFpwVp2OnCjzl3y5ZmbnGNc8ISp93UwUhBBsN02r1KO p5mG2BBwG+BrYx9wNiPhOY67tyglAcbAHv6JeRnTn+raYqogi7bqM1p88F3DH2v1QfID nhw5rQ53i/BH5I6xt1q3cb/TBEJtj+5HfIP5t2FPxTfNlcS/gNx3RNzWF48j8YVhOtwg 92dg== X-Gm-Message-State: AOAM533GEhDpI410KGVXglaWnhfw7vpHVWEHpDs1YJO2EWgfWQwsudkt AVcsAtm1uqV2Qwj9HD9lcsJgVil0enXwCm/kLRs= X-Google-Smtp-Source: ABdhPJxmowSx+KJEU18UYNOskFKmZRKVBdDd5f/H2kOa8idYnDOi39AjuirZ/uI5P0lA8z1ePuToVDbs95T0Tpl14SA= X-Received: by 2002:a02:a310:: with SMTP id q16mr24063079jai.8.1625691536771; Wed, 07 Jul 2021 13:58:56 -0700 (PDT) Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20ad13eb229b15fd14d870832d43a1605ba5c24a.camel@HansenPartnership.com> <1f2a62c19845e4602817c2130d47bbea02d04d1d.camel@HansenPartnership.com> In-Reply-To: From: Miguel Ojeda Date: Wed, 7 Jul 2021 22:58:44 +0200 Message-ID: Subject: Re: [TECH TOPIC] Rust for Linux To: Greg KH Cc: Wedson Almeida Filho , James Bottomley , Julia Lawall , Laurent Pinchart , Linus Walleij , Roland Dreier , ksummit@lists.linux.dev Content-Type: text/plain; charset="UTF-8" On Wed, Jul 7, 2021 at 7:20 PM Greg KH wrote: > > That's not what I meant by bringing up a kref. I was trying to ask > where the "real" lock here is. It has to be somewhere... Given this sentence, I think I understand where the confusion comes from. The key is that `Ref` (`Arc`) is not adding any thread-safety to the `T` it wraps -- it is only concerned about providing reference-counting semantics. For that it only needs to keep a thread-safe refcount for a given `T`. But the `T` might be (or not!) thread-safe. Since the refcount is an atomic, that is enough for implementing `Ref`, no locks are needed. Now, if you need mutable access to the content of an `Ref` that is shared by several threads at the same time, you need something extra -- that is where you would need a lock. For instance, in normal Rust code you may see a `Arc>` being used. The big thing is that if you get any of this wrong, you get a compile-time error. For instance, if you create a `Ref` out of a `T` that is not marked as safe to be sent across threads, you get an error when you try to send the `Ref`. Or if you create a `Ref` and try to call a method that mutates the `T` across threads, you will also get a compile-time error. Thus you cannot forget to have a lock if it is needed. Cheers, Miguel