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 2141EC54EE9 for ; Tue, 20 Sep 2022 15:55:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231226AbiITPzq (ORCPT ); Tue, 20 Sep 2022 11:55:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229472AbiITPzp (ORCPT ); Tue, 20 Sep 2022 11:55:45 -0400 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F47543610; Tue, 20 Sep 2022 08:55:41 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]:36382) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1oafay-00BoIG-CD; Tue, 20 Sep 2022 09:55:36 -0600 Received: from ip68-110-29-46.om.om.cox.net ([68.110.29.46]:59828 helo=email.froward.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1oafaw-004fTi-Nm; Tue, 20 Sep 2022 09:55:36 -0600 From: "Eric W. Biederman" To: Linus Torvalds Cc: Alex Gaynor , Wedson Almeida Filho , Matthew Wilcox , Kees Cook , Miguel Ojeda , Konstantin Shelekhin , ojeda@kernel.org, ark.email@gmail.com, bjorn3_gh@protonmail.com, bobo1239@web.de, bonifaido@gmail.com, boqun.feng@gmail.com, davidgow@google.com, dev@niklasmohrin.de, dsosnowski@dsosnowski.pl, foxhlchen@gmail.com, gary@garyguo.net, geofft@ldpreload.com, gregkh@linuxfoundation.org, jarkko@kernel.org, john.m.baublitz@gmail.com, leseulartichaut@gmail.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, me@kloenk.de, milan@mdaverde.com, mjmouse9999@gmail.com, patches@lists.linux.dev, rust-for-linux@vger.kernel.org, thesven73@gmail.com, viktor@v-gar.de, Andreas Hindborg References: <20220805154231.31257-13-ojeda@kernel.org> Date: Tue, 20 Sep 2022 10:55:27 -0500 In-Reply-To: (Linus Torvalds's message of "Mon, 19 Sep 2022 17:15:13 -0700") Message-ID: <87a66uxcpc.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1oafaw-004fTi-Nm;;;mid=<87a66uxcpc.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.110.29.46;;;frm=ebiederm@xmission.com;;;spf=softfail X-XM-AID: U2FsdGVkX1/feQ3pgxQ1gVLYi+MOVKIy82mZEHw2pBM= X-SA-Exim-Connect-IP: 68.110.29.46 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v9 12/27] rust: add `kernel` crate X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: rust-for-linux@vger.kernel.org Linus Torvalds writes: > On Mon, Sep 19, 2022 at 4:58 PM Linus Torvalds > wrote: >> >> This is not some kind of "a few special things". >> >> This is things like absolutely _anything_ that allocates memory, or >> takes a lock, or does a number of other things. > > Examples of "number of other things" ends up being things like > "accessing user memory", which depending on what you are doing may be > very common too. > > And btw, it's not only about the (multiple kinds of) atomic regions. > > We have other context rules in the kernel too, like "does floating > point or vector unit calculations". Which you can actually do, but > only in a kernel_fpu_begin/kernel_fpu_end region. > > Now, the floating point thing is rare enough that it's probably fine > to just say "no floating point at all in Rust code". It tends to be > very special code, so you'd write it in C or inline assembly, because > you're doing special things like using the vector unit for crypto > hashes using special CPU instructions. I just want to point out that there are ways of representing things like the context you are running in during compile time. I won't argue they are necessarily practical, but there are ways and by exploring those ways some practical solutions may result. Instead of saying: spin_lock(&lock); do_something(); spin_unlock(&lock); It is possible to say: with_spin_lock(&lock, do_something()); This can be taken a step farther and with_spin_lock can pass a ``token'' say a structure with no members that disappears at compile time that let's the code know it has the spinlock held. In C I would do: struct have_spin_lock_x { // nothing }; do_something(struct have_spin_lock_x context_guarantee) { ...; } I think most of the special contexts in the kernel can be represented in a similar manner. A special parameter that can be passed and will compile out. I don't recall seeing anything like that tried in the kernel so I don't know if it makes sense or if it would get too wordy to live, but it is possible. If passing a free context parameter is not too wordy it would catch silly errors, and would hopefully leave more mental space for developers to pay attention to the other details of the problems they are solving. *Shrug* I don't know if rust allows for free parameters like that and if it does I don't know if it would be cheap enough to live. Eric