From: Wedson Almeida Filho <wedsonaf@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Wilcox <willy@infradead.org>,
Kees Cook <keescook@chromium.org>,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Konstantin Shelekhin <k.shelekhin@yadro.com>,
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 <andreas.hindborg@wdc.com>
Subject: Re: [PATCH v9 12/27] rust: add `kernel` crate
Date: Mon, 19 Sep 2022 23:35:35 +0100 [thread overview]
Message-ID: <Yyjut3MHooCwzHRc@wedsonaf-dev> (raw)
In-Reply-To: <CAHk-=whm5Ujw-yroDPZWRsHK76XxZWF1E9806jNOicVTcQC6jw@mail.gmail.com>
On Mon, Sep 19, 2022 at 01:42:44PM -0700, Linus Torvalds wrote:
> On Mon, Sep 19, 2022 at 11:05 AM Wedson Almeida Filho
> <wedsonaf@gmail.com> 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.
No one is talking about absolute safety guarantees. I am talking about
specific ones that Rust makes: these are well-documented and formally
defined.
> 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.
While I disagree with some of what you write, the point is taken.
But I won't give up on Rust guarantees just yet, I'll try to find
ergonomic ways to enforce them at compile time.
Thanks,
-Wedson
next prev parent reply other threads:[~2022-09-19 22:35 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-05 15:41 [PATCH v9 00/27] Rust support Miguel Ojeda
2022-08-05 15:41 ` [PATCH v9 01/27] kallsyms: use `sizeof` instead of hardcoded size Miguel Ojeda
2022-08-05 16:48 ` Geert Stappers
2022-08-05 18:46 ` Miguel Ojeda
2022-08-05 22:40 ` Konstantin Shelekhin
2022-08-17 19:36 ` Kees Cook
2022-08-18 9:03 ` Konstantin Shelekhin
2022-08-18 16:03 ` Kees Cook
2022-09-27 12:48 ` Miguel Ojeda
2022-08-05 15:41 ` [PATCH v9 02/27] kallsyms: avoid hardcoding buffer size Miguel Ojeda
2022-08-17 19:37 ` Kees Cook
2022-08-18 16:50 ` Geert Stappers
2022-08-05 15:41 ` [PATCH v9 03/27] kallsyms: add static relationship between `KSYM_NAME_LEN{,_BUFFER}` Miguel Ojeda
2022-08-17 19:39 ` Kees Cook
2022-08-17 19:50 ` Boqun Feng
2022-08-17 20:31 ` Kees Cook
2022-08-17 20:45 ` Miguel Ojeda
2022-08-05 15:41 ` [PATCH v9 04/27] kallsyms: support "big" kernel symbols Miguel Ojeda
2022-08-05 15:41 ` [PATCH v9 05/27] kallsyms: increase maximum kernel symbol length to 512 Miguel Ojeda
2022-08-05 15:41 ` [PATCH v9 06/27] rust: add C helpers Miguel Ojeda
2022-08-17 19:44 ` Kees Cook
2022-08-17 20:22 ` Miguel Ojeda
2022-08-17 20:34 ` Kees Cook
2022-08-17 21:44 ` Miguel Ojeda
2022-08-17 23:56 ` Kees Cook
2022-08-18 16:03 ` Miguel Ojeda
2022-08-18 16:08 ` Kees Cook
2022-08-18 17:01 ` Miguel Ojeda
2022-08-05 15:41 ` [PATCH v9 07/27] rust: import upstream `alloc` crate Miguel Ojeda
2022-08-17 20:07 ` Kees Cook
2022-08-17 21:00 ` Miguel Ojeda
2022-08-05 15:41 ` [PATCH v9 08/27] rust: adapt `alloc` crate to the kernel Miguel Ojeda
2022-08-05 15:41 ` [PATCH v9 09/27] rust: add `compiler_builtins` crate Miguel Ojeda
2022-08-17 20:08 ` Kees Cook
2022-08-22 23:55 ` Nick Desaulniers
2022-08-24 18:38 ` Nick Desaulniers
2022-08-29 17:11 ` Gary Guo
2022-08-05 15:41 ` [PATCH v9 10/27] rust: add `macros` crate Miguel Ojeda
2022-08-05 15:41 ` [PATCH v9 11/27] rust: add `bindings` crate Miguel Ojeda
2022-08-05 15:41 ` [PATCH v9 12/27] rust: add `kernel` crate Miguel Ojeda
2022-08-06 10:24 ` Konstantin Shelekhin
2022-08-06 11:22 ` Miguel Ojeda
2022-08-06 12:15 ` Konstantin Shelekhin
2022-08-06 14:57 ` Matthew Wilcox
2022-09-19 14:07 ` Wedson Almeida Filho
2022-09-19 16:09 ` Linus Torvalds
2022-09-19 17:20 ` Linus Torvalds
2022-09-19 18:05 ` Wedson Almeida Filho
2022-09-19 20:42 ` Linus Torvalds
2022-09-19 22:35 ` Wedson Almeida Filho [this message]
2022-09-19 23:39 ` Linus Torvalds
2022-09-19 23:50 ` Alex Gaynor
2022-09-19 23:58 ` Linus Torvalds
2022-09-20 0:15 ` Linus Torvalds
2022-09-20 15:55 ` Eric W. Biederman
2022-09-20 22:39 ` Gary Guo
2022-09-21 6:42 ` comex
2022-09-21 14:19 ` Boqun Feng
2022-10-03 2:03 ` comex
2022-09-20 0:40 ` Boqun Feng
2022-10-03 4:17 ` Kyle Strand
2022-09-20 0:41 ` Wedson Almeida Filho
2022-09-21 11:23 ` Konstantin Shelekhin
2022-09-21 11:46 ` Greg KH
2022-08-05 15:41 ` [PATCH v9 13/27] rust: export generated symbols Miguel Ojeda
2022-08-17 20:11 ` Kees Cook
2022-08-05 15:41 ` [PATCH v9 14/27] vsprintf: add new `%pA` format specifier Miguel Ojeda
2022-08-05 15:42 ` [PATCH v9 15/27] scripts: checkpatch: diagnose uses of `%pA` in the C side as errors Miguel Ojeda
2022-08-05 15:42 ` [PATCH v9 16/27] scripts: checkpatch: enable language-independent checks for Rust Miguel Ojeda
2022-08-17 20:12 ` Kees Cook
2022-08-05 15:42 ` [PATCH v9 17/27] scripts: decode_stacktrace: demangle Rust symbols Miguel Ojeda
2022-08-05 15:42 ` [PATCH v9 18/27] scripts: add `generate_rust_analyzer.py` Miguel Ojeda
2022-08-17 20:13 ` Kees Cook
2022-08-05 15:42 ` [PATCH v9 19/27] scripts: add `generate_rust_target.rs` Miguel Ojeda
2022-08-17 20:14 ` Kees Cook
2022-08-05 15:42 ` [PATCH v9 20/27] scripts: add `rust_is_available.sh` Miguel Ojeda
2022-08-17 20:18 ` Kees Cook
2022-08-17 20:40 ` Miguel Ojeda
2022-08-22 20:09 ` Nick Desaulniers
2022-08-23 12:12 ` Miguel Ojeda
2022-08-23 12:16 ` Miguel Ojeda
2022-08-05 15:42 ` [PATCH v9 21/27] scripts: add `is_rust_module.sh` Miguel Ojeda
2022-08-17 20:19 ` Kees Cook
2022-08-05 15:42 ` [PATCH v9 22/27] rust: add `.rustfmt.toml` Miguel Ojeda
2022-08-17 20:19 ` Kees Cook
2022-08-05 15:42 ` [PATCH v9 23/27] Kbuild: add Rust support Miguel Ojeda
2022-08-17 20:26 ` Kees Cook
2022-08-17 20:56 ` Miguel Ojeda
2022-08-22 22:35 ` Nick Desaulniers
2022-09-12 16:07 ` Masahiro Yamada
2022-09-12 16:18 ` Miguel Ojeda
2022-09-13 6:37 ` Masahiro Yamada
2022-08-05 15:42 ` [PATCH v9 24/27] docs: add Rust documentation Miguel Ojeda
2022-08-05 15:42 ` [PATCH v9 25/27] x86: enable initial Rust support Miguel Ojeda
2022-08-17 20:27 ` Kees Cook
2022-08-05 15:42 ` [PATCH v9 26/27] samples: add first Rust examples Miguel Ojeda
2022-08-06 13:14 ` Konstantin Shelekhin
2022-08-17 21:02 ` Miguel Ojeda
2022-08-18 9:04 ` Konstantin Shelekhin
2022-08-17 20:28 ` Kees Cook
2022-08-05 15:42 ` [PATCH v9 27/27] MAINTAINERS: Rust Miguel Ojeda
2022-08-17 20:28 ` Kees Cook
2022-08-17 20:43 ` Miguel Ojeda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yyjut3MHooCwzHRc@wedsonaf-dev \
--to=wedsonaf@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=andreas.hindborg@wdc.com \
--cc=ark.email@gmail.com \
--cc=bjorn3_gh@protonmail.com \
--cc=bobo1239@web.de \
--cc=bonifaido@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=davidgow@google.com \
--cc=dev@niklasmohrin.de \
--cc=dsosnowski@dsosnowski.pl \
--cc=foxhlchen@gmail.com \
--cc=gary@garyguo.net \
--cc=geofft@ldpreload.com \
--cc=gregkh@linuxfoundation.org \
--cc=jarkko@kernel.org \
--cc=john.m.baublitz@gmail.com \
--cc=k.shelekhin@yadro.com \
--cc=keescook@chromium.org \
--cc=leseulartichaut@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.falkowski@samsung.com \
--cc=me@kloenk.de \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=milan@mdaverde.com \
--cc=mjmouse9999@gmail.com \
--cc=ojeda@kernel.org \
--cc=patches@lists.linux.dev \
--cc=rust-for-linux@vger.kernel.org \
--cc=thesven73@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=viktor@v-gar.de \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).