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 38168C6FA82 for ; Mon, 19 Sep 2022 20:43:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229589AbiISUnU (ORCPT ); Mon, 19 Sep 2022 16:43:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229647AbiISUnS (ORCPT ); Mon, 19 Sep 2022 16:43:18 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BB7B048E84 for ; Mon, 19 Sep 2022 13:43:17 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id y3so1513614ejc.1 for ; Mon, 19 Sep 2022 13:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=axFkS9Utlog4o8yvW7z9cdhHkfxEIm+Wjlvn5hdmsPA=; b=Bol7xpNVdUt4dkpqIrlKRbKtSZ69qX8bFD7bM+UNptU6uew8jXanmgFFa2RaCjw/0K Viuw5KoW880GDkvlaepJfO1oNA6zu651EVs7nm6Ol+j+Qse3GrQl7IegVb+xVn3hyBjy DGilG+n8/9qEUM0E90L3OPfddms9ynHNQP4ec= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=axFkS9Utlog4o8yvW7z9cdhHkfxEIm+Wjlvn5hdmsPA=; b=PM47qZDfF3DjxElqDVaqZUf1jVMu8wiJBW/UjS3srwh+I0hg2IdO/bpMBc5MdYONTT 1VI2TeHUm6USqR6Q1d58LBbQ6iDKmIlb4KT8cMaPGNNz9kB7STDiYmZPT+Es2lAA/pai ScrYdCg6IlGzLg73UebU2wEajlf3ROHgFVi8MR4Zft8PDd7A7QAdKT3Bj0TJBY+v5RAW NfRPEzZfQYZmQIIc7hIXpWZRAXIYtGcEB4Q4M0Z8gYdTvxl+eUU94ELDqmenB5T/qv/9 c1P1xqjcaq5R3G/kSkytCTuyzf4ZhKobK0qvCVxUbTZXrVSbKcbrcedlEDRGG24FvCij tNsw== X-Gm-Message-State: ACrzQf0FTR1lItOxgk1mW5NkFQNgKvKdOZdQ8GhAmQMpLWbCGD3gULaH 5S0oEszvKHfoQ+u3FTZrw2S5Y+THce6Ck6DK1yY= X-Google-Smtp-Source: AMsMyM6R9iUpwKBU+47cXSkJjPD7i3tGoEE4Aa3lD00mhtNRrHXxSY58KZ3qIJ71v9PakBvDf5FLWg== X-Received: by 2002:a17:907:b12:b0:774:53bb:52a3 with SMTP id h18-20020a1709070b1200b0077453bb52a3mr13591026ejl.258.1663620195121; Mon, 19 Sep 2022 13:43:15 -0700 (PDT) Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com. [209.85.218.51]) by smtp.gmail.com with ESMTPSA id h20-20020a50ed94000000b00447e5983478sm20914355edr.76.2022.09.19.13.43.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Sep 2022 13:43:14 -0700 (PDT) Received: by mail-ej1-f51.google.com with SMTP id lh5so1401442ejb.10 for ; Mon, 19 Sep 2022 13:43:12 -0700 (PDT) X-Received: by 2002:a2e:b4ad:0:b0:26c:24f:b260 with SMTP id q13-20020a2eb4ad000000b0026c024fb260mr5573619ljm.173.1663620181394; Mon, 19 Sep 2022 13:43:01 -0700 (PDT) MIME-Version: 1.0 References: <20220805154231.31257-13-ojeda@kernel.org> In-Reply-To: From: Linus Torvalds Date: Mon, 19 Sep 2022 13:42:44 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v9 12/27] rust: add `kernel` crate To: Wedson Almeida Filho Cc: Matthew Wilcox , Kees Cook , Miguel Ojeda , Konstantin Shelekhin , ojeda@kernel.org, alex.gaynor@gmail.com, 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, m.falkowski@samsung.com, 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: rust-for-linux@vger.kernel.org On Mon, Sep 19, 2022 at 11:05 AM Wedson Almeida Filho wrote: > > As you know, we're trying to guarantee the absence of undefined > behaviour for code written in Rust. And the context is _really_ > important, so important that leaving it up to comments isn't enough. You need to realize that (a) reality trumps fantasy (b) kernel needs trump any Rust needs And the *reality* is that there are no absolute guarantees. Ever. The "Rust is safe" is not some kind of absolute guarantee of code safety. Never has been. Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus. Even "safe" rust code in user space will do things like panic when things go wrong (overflows, allocation failures, etc). If you don't realize that that is NOT some kind of true safely, I don't know what to say. Not completing the operation at all, is *not* really any better than getting the wrong answer, it's only more debuggable. In the kernel, "panic and stop" is not an option (it's actively worse than even the wrong answer, since it's really not debugable), so the kernel version of "panic" is "WARN_ON_ONCE()" and continue with the wrong answer. So this is something that I really *need* the Rust people to understand. That whole reality of "safe" not being some absolute thing, and the reality that the kernel side *requires* slightly different rules than user space traditionally does. > I don't care as much about allocation flags as I do about sleeping in an > rcu read-side critical region. When CONFIG_PREEMPT=n, if some CPU makes > the mistake of sleeping between rcu_read_lock()/rcu_read_unlock(), RCU > will take that as a quiescent state, which may cause unsuspecting code > waiting for a grace period to wake up too early and potentially free > memory that is still in use, which is obviously undefined behaviour. So? You had a bug. Shit happens. We have a lot of debugging tools that will give you a *HUGE* warning when said shit happens, including sending automated reports to the distro maker. And then you fix the bug. Think of that "debugging tools give a huge warning" as being the equivalent of std::panic in standard rust. Yes, the kernel will continue (unless you have panic-on-warn set), because the kernel *MUST* continue in order for that "report to upstream" to have a chance of happening. So it's technically a veryu different implementation from std:panic, but you should basically see it as exactly that: a *technical* difference, not a conceptual one. The rules for how the kernel deals with bugs is just different, because we don't have core-files and debuggers in the general case. (And yes, you can have a kernel debugger, and you can just have the WARN_ON_ONCE trigger the debugger, but think of all those billions of devices that are in normal users hands). And yes, in certain configurations, even those warnings will be turned off because the state tracking isn't done. Again, that's just reality. You don't need to use those configurations yourself if you don't like them, but that does *NOT* mean that you get to say "nobody else gets to use those configurations either". Deal with it. Or, you know, if you can't deal with the rules that the kernel requires, then just don't do kernel programming. Because in the end it really is that simple. I really need you to understand that Rust in the kernel is dependent on *kernel* rules. Not some other random rules that exist elsewhere. Linus