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 2727BC6FA8B for ; Mon, 19 Sep 2022 23:58:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229881AbiISX6o (ORCPT ); Mon, 19 Sep 2022 19:58:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229605AbiISX6k (ORCPT ); Mon, 19 Sep 2022 19:58:40 -0400 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A48B051408 for ; Mon, 19 Sep 2022 16:58:39 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id a26so2370350ejc.4 for ; Mon, 19 Sep 2022 16:58:39 -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=k3xlnAyuOJefFP7D3SzMTJMGo96xFtxvnNEEJ0Y5xB0=; b=CELKTFYiDZ28jArQvDpCb7qvvmdR8edtKyTcfxOM06jxTtB2qlY/zEckJKnjqVYSUg /1qq7YY2fOwFzO8ZWvQluuxKF4YNZ/cX2DQjVxmpBio5Cm9RlMhyOPAY60phndmXv31l qegbKlImOq5akFoRY3p69urdyJAV4aubfYBpc= 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=k3xlnAyuOJefFP7D3SzMTJMGo96xFtxvnNEEJ0Y5xB0=; b=HZrQ6igUQrgOsz2+nC0FEZ4exlofWXH8QcMnJPrAEUwOQyIVyRRZeA05Q6NGw4wdoy eQ9VFsF0KtU1ckFZMtv6NIBDFZVPA3AiwFET3Z2OUp47dAOBFQKKyEogZLZKLaqpUlE4 UE33pSTPXv2DVxOr/Azy9OgR2Id4QUSsMyVid1OHRMwtOLTntq6Md0ciC180vf2ln80z D52HKpBHqgwa9zuqq2orGe/tPKdV+X4eQxOJJ+jWllO9QYIO1tYI+4jxYFGYQBi+FNtU ZlB57tFyCKUaicQfzBecG1HmwpuvSRoj1mP6RwPBXGj1hMPVdVTfdUteqPx/5V6HW6sn wRpw== X-Gm-Message-State: ACrzQf0ng4s0wHgZJJ8XWCujpPxFP/10QzkJvN57jI1zmLwG9HPc6kPW gKJ67K/NUWYbx83+AilI3mcBCCVlM6WZPemcLfU= X-Google-Smtp-Source: AMsMyM6WGtwjHjmuh6mUNkMdyTXp3A2298vu+SkXY7vHAL+Zhe2TtELhTKzJUV7N6AVxL5WRBIV63A== X-Received: by 2002:a17:906:4fd1:b0:781:35c1:3664 with SMTP id i17-20020a1709064fd100b0078135c13664mr6664559ejw.140.1663631917473; Mon, 19 Sep 2022 16:58:37 -0700 (PDT) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com. [209.85.221.45]) by smtp.gmail.com with ESMTPSA id u8-20020a50eac8000000b004536d530ca5sm25658edp.38.2022.09.19.16.58.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Sep 2022 16:58:37 -0700 (PDT) Received: by mail-wr1-f45.google.com with SMTP id bq9so1625030wrb.4 for ; Mon, 19 Sep 2022 16:58:34 -0700 (PDT) X-Received: by 2002:ac2:5cd7:0:b0:49f:ae59:3b87 with SMTP id f23-20020ac25cd7000000b0049fae593b87mr2724088lfq.291.1663631903618; Mon, 19 Sep 2022 16:58:23 -0700 (PDT) MIME-Version: 1.0 References: <20220805154231.31257-13-ojeda@kernel.org> In-Reply-To: From: Linus Torvalds Date: Mon, 19 Sep 2022 16:58:06 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v9 12/27] rust: add `kernel` crate To: Alex Gaynor Cc: 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, 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: linux-kernel@vger.kernel.org On Mon, Sep 19, 2022 at 4:50 PM Alex Gaynor wrote: > > Rust's rules are that a function that's safe must not exhibit UB, no > matter what arguments they're called with. This can be done with > static checking or dynamic checking, with obvious trade offs between > the two. I think you are missing just how many things are "unsafe" in certain contexts and *cannot* be validated. 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. Those things are simply not "safe" if you hold a spinlock, or if you are in a RCU read-locked region. And there is literally no way to check for it in certain configurations. None. So are you going to mark every single function that takes a mutex as being "unsafe"? Or are you just going to accept and understand that "hey, exactly like with integer overflows, sometimes it will be checked, and sometimes it just won't be". Because that is literally the reality of the kernel. Sometimes you WILL NOT have the checks, and you literally CANNOT have the checks. This is just how reality is. You don't get to choose the universe you live in. Linus