From: Wedson Almeida Filho <wedsonaf@google.com> To: Peter Zijlstra <peterz@infradead.org> Cc: ojeda@kernel.org, Linus Torvalds <torvalds@linux-foundation.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, rust-for-linux@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/13] [RFC] Rust support Date: Fri, 16 Apr 2021 16:33:51 +0100 [thread overview] Message-ID: <YHmuX1NA5RF7C7XS@google.com> (raw) In-Reply-To: <YHmc2+bKQJ/XAATF@hirez.programming.kicks-ass.net> On Fri, Apr 16, 2021 at 04:19:07PM +0200, Peter Zijlstra wrote: > Does this also not prohibit constructs where modification must be done > while holding two locks, but reading can be done while holding either > lock? I don't believe it does. Remember that we have full control of the abstractions, so we can (and will when the need arises) build an abstraction that provides the functionality you describe. For the read path, we can have functions that return a read-only guard (which is the gateway to the data in Rust) when locking either of the locks, or when showing evidence that either lock is already locked (i.e., by temporarily transferring ownership of another guard). Note that this is another area where Rust offers advantages: read-only guards (in C, if you take a read lock, nothing prevents you from making changes to fields you should only be allowed to read); and the ability to take temporary ownership, giving it back even within the same function. Similarly, to access a mutable guard, you'd have to show evidence that both locks are held. > That's a semi common scheme in the kernel, but not something that's > expressible by, for example, the Java sync keyword. > > It also very much doesn't work for RCU, where modification must be done > under a lock, but access is done essentially lockless. Why not? RCU is a lock -- it may have zero cost in most (all?) architectures on the read path, but it is a lock. We can model access to variables/fields protected by it just like any other lock, with the implementation of lock/unlock optimizing to no-ops on the read path where possible. In fact, this is also an advantage of Rust. It would *force* developers to lock/unlock the RCU lock before they can access the protected data. > I would much rather have a language extention where we can associate > custom assertions with variable access, sorta like a sanitizer: > > static inline void assert_foo_bar(struct foo *f) > { > lockdep_assert_held(&f->lock); > } > > struct foo { > spinlock_t lock; > int bar __assert__(assert_foo_bar); > }; > > Such things can be optional and only enabled for debug builds on new > compilers. These would be great, but would still fall short of the compile-time guaranteed safety that Rust offers in these cases. > C does indeed not have the concept of ownership, unlike modern C++ I > think. But I would much rather see a C language extention for that than > go Rust. > > This would mean a far more agressive push for newer C compilers than > we've ever done before, but at least it would all still be a single > language. Convertion to the new stuff can be done gradually and where > it makes sense and new extentions can be evaluated on performance impact > etc. I encourage you to pursue this. We'd all benefit from better C. I'd be happy to review and provide feedback on proposed extensions that are deemed equivalent/better than what Rust offers. My background is also in C. I'm no Rust fanboy, I'm just taking what I think is a pragmatic view of the available options.
next prev parent reply other threads:[~2021-04-16 15:34 UTC|newest] Thread overview: 189+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-14 18:45 ojeda 2021-04-14 18:45 ` [PATCH 01/13] kallsyms: Support "big" kernel symbols (2-byte lengths) ojeda 2021-04-14 19:44 ` Matthew Wilcox 2021-04-14 19:59 ` Miguel Ojeda 2021-04-14 18:45 ` [PATCH 02/13] kallsyms: Increase maximum kernel symbol length to 512 ojeda 2021-04-14 23:48 ` Nick Desaulniers 2021-04-14 18:45 ` [PATCH 03/13] Makefile: Generate CLANG_FLAGS even in GCC builds ojeda 2021-04-14 18:59 ` Nathan Chancellor 2021-04-15 10:18 ` Miguel Ojeda 2021-04-14 23:46 ` Nick Desaulniers 2021-04-15 0:47 ` Miguel Ojeda 2021-04-14 18:45 ` [PATCH 04/13] Kbuild: Rust support ojeda 2021-04-14 23:19 ` Nick Desaulniers 2021-04-15 0:43 ` Miguel Ojeda 2021-04-15 18:03 ` Nick Desaulniers 2021-04-16 12:23 ` Miguel Ojeda 2021-04-17 19:35 ` Masahiro Yamada 2021-04-16 13:38 ` Peter Zijlstra 2021-04-16 17:05 ` Linus Torvalds 2021-04-16 17:47 ` Miguel Ojeda 2021-04-16 18:09 ` Al Viro 2021-04-16 18:57 ` Miguel Ojeda 2021-04-16 20:22 ` Willy Tarreau 2021-04-16 20:34 ` Connor Kuehl 2021-04-16 20:58 ` Willy Tarreau 2021-04-16 21:39 ` Miguel Ojeda 2021-04-16 22:04 ` Willy Tarreau 2021-04-16 22:45 ` Al Viro 2021-04-16 23:46 ` Miguel Ojeda 2021-04-17 4:24 ` Willy Tarreau 2021-04-17 15:38 ` Miguel Ojeda 2021-04-16 21:19 ` Miguel Ojeda 2021-04-16 17:34 ` Miguel Ojeda 2021-04-19 19:58 ` David Sterba 2021-04-19 20:17 ` Matthew Wilcox 2021-04-19 21:03 ` Miguel Ojeda 2021-04-19 20:54 ` Miguel Ojeda 2021-04-14 18:45 ` [PATCH 05/13] Rust: Compiler builtins crate ojeda 2021-04-14 19:19 ` Linus Torvalds 2021-04-14 19:34 ` Miguel Ojeda 2021-04-14 18:45 ` [PATCH 06/13] Rust: Module crate ojeda 2021-04-14 18:45 ` [PATCH 07/13] Rust: Kernel crate ojeda 2021-04-14 19:31 ` Linus Torvalds 2021-04-14 19:50 ` Miguel Ojeda 2021-04-14 18:45 ` [PATCH 08/13] Rust: Export generated symbols ojeda 2021-04-14 18:46 ` [PATCH 09/13] Samples: Rust examples ojeda 2021-04-14 19:34 ` Linus Torvalds 2021-04-14 19:42 ` Miguel Ojeda 2021-04-14 19:49 ` Matthew Wilcox 2021-04-16 11:46 ` Andrej Shadura 2021-04-14 23:24 ` Nick Desaulniers 2021-04-15 7:10 ` Greg Kroah-Hartman 2021-04-15 7:39 ` Nick Desaulniers 2021-04-15 12:42 ` Miguel Ojeda 2021-04-16 13:07 ` Sven Van Asbroeck 2021-04-16 13:20 ` Greg Kroah-Hartman 2021-04-14 18:46 ` [PATCH 10/13] Documentation: Rust general information ojeda 2021-04-14 22:17 ` Nick Desaulniers 2021-04-14 23:34 ` Miguel Ojeda 2021-04-14 18:46 ` [PATCH 11/13] MAINTAINERS: Rust ojeda 2021-04-14 21:55 ` Nick Desaulniers 2021-04-14 22:02 ` Miguel Ojeda 2021-04-14 22:36 ` Nick Desaulniers 2021-04-14 18:46 ` [PATCH 12/13] Rust: add abstractions for Binder (WIP) ojeda 2021-04-14 18:46 ` [PATCH 13/13] Android: Binder IPC in Rust (WIP) ojeda 2021-04-14 19:44 ` [PATCH 00/13] [RFC] Rust support Linus Torvalds 2021-04-14 20:20 ` Miguel Ojeda 2021-04-15 1:38 ` Kees Cook 2021-04-15 8:26 ` David Laight 2021-04-15 18:08 ` Kees Cook 2021-04-15 12:39 ` Miguel Ojeda 2021-04-14 20:09 ` Matthew Wilcox 2021-04-14 20:21 ` Linus Torvalds 2021-04-14 20:35 ` Josh Triplett 2021-04-14 22:08 ` David Laight 2021-04-14 20:29 ` Miguel Ojeda 2021-04-18 15:31 ` Wedson Almeida Filho 2021-04-15 0:22 ` Nick Desaulniers 2021-04-15 10:05 ` Miguel Ojeda 2021-04-15 18:58 ` Peter Zijlstra 2021-04-16 2:22 ` Wedson Almeida Filho 2021-04-16 4:25 ` Al Viro 2021-04-16 5:02 ` Wedson Almeida Filho 2021-04-16 5:39 ` Paul Zimmerman 2021-04-16 7:46 ` Peter Zijlstra 2021-04-16 7:09 ` Peter Zijlstra 2021-04-17 5:23 ` comex 2021-04-17 12:46 ` David Laight 2021-04-17 14:51 ` Paolo Bonzini 2021-04-19 7:32 ` Peter Zijlstra 2021-04-19 7:53 ` Paolo Bonzini 2021-04-19 8:26 ` Peter Zijlstra 2021-04-19 8:35 ` Peter Zijlstra 2021-04-19 9:02 ` Paolo Bonzini 2021-04-19 9:36 ` Peter Zijlstra 2021-04-19 9:40 ` Paolo Bonzini 2021-04-19 11:01 ` Will Deacon 2021-04-19 17:14 ` Linus Torvalds 2021-04-19 18:38 ` Paolo Bonzini 2021-04-19 18:50 ` Linus Torvalds 2021-04-22 10:03 ` Linus Walleij 2021-04-22 14:09 ` David Laight 2021-04-22 15:24 ` Wedson Almeida Filho 2021-04-26 0:18 ` Linus Walleij 2021-04-26 14:26 ` Miguel Ojeda 2021-04-26 14:40 ` Wedson Almeida Filho 2021-04-26 16:03 ` Miguel Ojeda 2021-04-27 10:54 ` Linus Walleij 2021-04-27 11:13 ` Robin Randhawa 2021-04-29 1:52 ` Wedson Almeida Filho 2021-04-26 18:01 ` Miguel Ojeda 2021-04-22 21:28 ` Miguel Ojeda 2021-04-26 0:31 ` Linus Walleij 2021-04-26 18:18 ` Miguel Ojeda 2021-04-27 11:13 ` Linus Walleij 2021-04-28 2:51 ` Kyle Strand 2021-04-28 3:10 ` Miguel Ojeda 2021-05-04 21:21 ` Linus Walleij 2021-05-04 23:30 ` Miguel Ojeda 2021-05-05 11:34 ` Linus Walleij 2021-05-05 14:17 ` Miguel Ojeda 2021-05-05 15:13 ` Enrico Weigelt, metux IT consult 2021-05-06 12:47 ` Linus Walleij 2021-05-07 18:23 ` Miguel Ojeda 2021-04-16 4:27 ` Boqun Feng 2021-04-16 6:04 ` Nick Desaulniers 2021-04-16 18:47 ` Paul E. McKenney 2021-04-19 20:35 ` Nick Desaulniers 2021-04-19 21:37 ` Paul E. McKenney 2021-04-19 22:03 ` Miguel Ojeda 2021-04-16 20:48 ` Josh Triplett 2021-04-16 8:16 ` Michal Kubecek 2021-04-16 9:29 ` Willy Tarreau 2021-04-16 11:24 ` Peter Zijlstra 2021-04-16 13:07 ` Wedson Almeida Filho 2021-04-16 14:19 ` Peter Zijlstra 2021-04-16 15:04 ` Miguel Ojeda 2021-04-16 15:43 ` Peter Zijlstra 2021-04-16 16:21 ` Miguel Ojeda 2021-04-16 15:33 ` Wedson Almeida Filho [this message] 2021-04-16 16:14 ` Willy Tarreau 2021-04-16 17:10 ` Miguel Ojeda 2021-04-16 17:18 ` Peter Zijlstra 2021-04-16 18:08 ` Matthew Wilcox 2021-04-17 11:17 ` Peter Zijlstra 2021-04-17 11:46 ` Willy Tarreau 2021-04-17 14:24 ` Peter Zijlstra 2021-04-17 14:36 ` Willy Tarreau 2021-04-17 13:46 ` David Laight 2021-04-16 17:37 ` Willy Tarreau 2021-04-16 17:46 ` Connor Kuehl 2021-04-20 0:24 ` Nick Desaulniers 2021-04-20 3:47 ` Willy Tarreau 2021-04-20 5:56 ` Greg Kroah-Hartman 2021-04-20 6:16 ` Willy Tarreau 2021-04-29 15:38 ` peter enderborg 2021-04-17 13:53 ` Wedson Almeida Filho 2021-04-17 14:21 ` Willy Tarreau 2021-04-17 15:23 ` Miguel Ojeda 2021-04-18 15:51 ` Wedson Almeida Filho 2021-04-17 12:41 ` David Laight 2021-04-17 13:01 ` Wedson Almeida Filho 2021-04-16 15:03 ` Matthew Wilcox 2021-04-17 13:29 ` Wedson Almeida Filho 2021-04-16 15:58 ` Theodore Ts'o 2021-04-16 16:21 ` Wedson Almeida Filho 2021-04-17 15:11 ` Paolo Bonzini 2021-04-16 14:21 ` Miguel Ojeda 2021-04-17 20:42 ` Richard Weinberger 2021-04-28 18:34 ` Mariusz Ceier 2021-04-28 20:25 ` Nick Desaulniers 2021-04-28 21:21 ` David Laight 2021-04-29 11:14 ` Kajetan Puchalski 2021-04-29 11:25 ` Kajetan Puchalski 2021-04-29 14:06 ` Mariusz Ceier 2021-04-29 14:13 ` Sven Van Asbroeck 2021-04-29 14:26 ` Willy Tarreau 2021-04-29 15:06 ` Al Viro 2021-04-29 16:09 ` Mariusz Ceier 2021-04-30 6:39 ` Thomas Schoebel-Theuer 2021-04-30 8:30 ` David Laight 2021-05-05 13:58 ` Enrico Weigelt, metux IT consult 2021-05-05 14:41 ` Miguel Ojeda 2022-06-20 15:11 ` Olliver Schinagl 2022-06-27 17:44 ` Miguel Ojeda 2021-04-29 5:20 Mariusz Ceier 2021-04-29 5:21 Mariusz Ceier 2021-04-29 8:18 ` David Laight 2021-07-30 23:22 Dillan Jackson
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=YHmuX1NA5RF7C7XS@google.com \ --to=wedsonaf@google.com \ --cc=gregkh@linuxfoundation.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kbuild@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=ojeda@kernel.org \ --cc=peterz@infradead.org \ --cc=rust-for-linux@vger.kernel.org \ --cc=torvalds@linux-foundation.org \ --subject='Re: [PATCH 00/13] [RFC] Rust support' \ /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
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).