From: Miguel Ojeda <ojeda@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [GIT PULL] Rust fixes for 6.2
Date: Tue, 24 Jan 2023 20:33:34 +0100 [thread overview]
Message-ID: <20230124193334.161057-1-ojeda@kernel.org> (raw)
Hi Linus,
This is the first "fixes" PR for Rust.
While it may be a bit early to have a "fixes" branch, I guessed it
would not hurt to start practicing how to do things for the future when
we may get actual users. And since the opportunity presented itself,
I wanted to also use this PR to bring up a "policy" topic and ideally
get kernel maintainers to think about it.
The PR contains a fix for a soundness issue, i.e. it closes a hole that
would allow somebody to write safe Rust code that is able to trigger
undefined behavior.
There are no actual cases of callers triggering this, so it is possible
to argue this is not a fix, which is fair. In other words, virtually
all C code suffers from these soundness holes, but obviously they are
not considered bugs. It is precisely this extra "layer" of protection
that Rust gives to source code that we think is valuable to the kernel.
On the other hand, others may argue they want soundness fixes to land,
and possibly even backported to stable, because they may run patched
kernels, out-of-tree modules, etc. and they may want to know if they
have a problem, even if that breaks their build.
Personally, for what is worth, I would support treating them as fixes.
But I do not want to create extra work for others until we have at
least some real users. So perhaps it should not go to stable?
The commit has been in linux-next for a week in a new branch called
rust-fixes. No conflicts expected. No changes to the C side.
Please pull -- thanks!
Cheers,
Miguel
The following changes since commit 5dc4c995db9eb45f6373a956eb1f69460e69e6d4:
Linux 6.2-rc4 (2023-01-15 09:22:43 -0600)
are available in the Git repository at:
https://github.com/Rust-for-Linux/linux tags/rust-fixes-6.2
for you to fetch changes up to 6618d69aa129a8fc613e64775d5019524c6f231b:
rust: print: avoid evaluating arguments in `pr_*` macros in `unsafe` blocks (2023-01-16 00:54:35 +0100)
----------------------------------------------------------------
Rust fixes for v6.2
A soundness fix:
- Avoid evaluating arguments in 'pr_*' macros in 'unsafe' blocks.
----------------------------------------------------------------
Miguel Ojeda (1):
rust: print: avoid evaluating arguments in `pr_*` macros in `unsafe` blocks
rust/kernel/print.rs | 29 ++++++++++++++++++-----------
1 file changed, 18 insertions(+), 11 deletions(-)
next reply other threads:[~2023-01-24 19:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-24 19:33 Miguel Ojeda [this message]
2023-01-25 2:23 ` [GIT PULL] Rust fixes for 6.2 pr-tracker-bot
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=20230124193334.161057-1-ojeda@kernel.org \
--to=ojeda@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=wedsonaf@gmail.com \
/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).