-
Notifications
You must be signed in to change notification settings - Fork 436
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add missing // SAFETY
comments
#351
Comments
There is an allow-by-default |
Here's a Python script to find undocumented import os
def check_safety_comments(path):
with open(path, 'r') as f:
last_safety_comment = False
for i, line in enumerate(f):
if 'unsafe {' in line and not line.lstrip().startswith('//') and not last_safety_comment:
print(f"{path}:{i + 1}: {line.strip()}")
if '// SAFETY' in line:
last_safety_comment = True
elif not line.lstrip().startswith('//') and line.strip() != '':
last_safety_comment = False
rust_dir = os.path.dirname(os.path.realpath(__file__))
kernel_dir = os.path.join(rust_dir, 'kernel')
for dirpath, _, filenames in os.walk(kernel_dir):
for filename in filenames:
if filename.endswith('.rs'):
check_safety_comments(os.path.join(dirpath, filename)) If placed in the |
Contributes to Rust-for-Linux#351 Added `// SAFETY` docs to `fn proc_handler` `rust/kernel/sysctl.rs:97:1` `rust/kernel/sysctl.rs:113:5` `rust/kernel/sysctl.rs:115:9` `rust/kernel/sysctl.rs:120:5` `rust/kernel/sysctl.rs:124:5` `rust/kernel/sysctl.rs:136:5` `rust/kernel/sysctl.rs:138:5` Added `// SAFETY` docs to `fn init_lock` `rust/kernel/sync/mutex.rs:85:9` Added `// SAFETY` docs to `fn init_lock` `rust/kernel/sync/spinlock.rs:144:9` Added `// SAFETY` docs to `fn init` `rust/kernel/sync/condvar.rs:135:9` Added `// SAFETY` docs to `fn read` `rust/kernel/pages.rs:96:9` Added `// SAFETY` docs to `fn write` `rust/kernel/pages.rs:125:9` Added `// SAFETY` docs to `fn rust_fmt_argument` `rust/kernel/print.rs:17:1` `rust/kernel/print.rs:62:5` Added `// SAFETY` docs to `fn set_param` `rust/kernel/module_param.rs:63:5` `rust/kernel/module_param.rs:74:13` `rust/kernel/module_param.rs:80:17` `rust/kernel/module_param.rs:83:17` Added `// SAFETY` docs to `fn get_param` `rust/kernel/module_param.rs:104:9` `rust/kernel/module_param.rs:108:9 Added `// SAFETY` docs to `fn free` `rust/kernel/module_param.rs:124:9 Signed-off-by: Dee-Jay Logozzo <git@djl.id.au>
Contributes to Rust-for-Linux#351 Added `// SAFETY` docs to `fn proc_handler` `rust/kernel/sysctl.rs:97:1` `rust/kernel/sysctl.rs:113:5` `rust/kernel/sysctl.rs:115:9` `rust/kernel/sysctl.rs:120:5` `rust/kernel/sysctl.rs:124:5` `rust/kernel/sysctl.rs:136:5` `rust/kernel/sysctl.rs:138:5` Added `// SAFETY` docs to `fn init_lock` `rust/kernel/sync/mutex.rs:85:9` Added `// SAFETY` docs to `fn init_lock` `rust/kernel/sync/spinlock.rs:144:9` Added `// SAFETY` docs to `fn init` `rust/kernel/sync/condvar.rs:135:9` Added `// SAFETY` docs to `fn read` `rust/kernel/pages.rs:96:9` Added `// SAFETY` docs to `fn write` `rust/kernel/pages.rs:125:9` Added `// SAFETY` docs to `fn rust_fmt_argument` `rust/kernel/print.rs:17:1` `rust/kernel/print.rs:62:5` Added `// SAFETY` docs to `fn set_param` `rust/kernel/module_param.rs:63:5` `rust/kernel/module_param.rs:74:13` `rust/kernel/module_param.rs:80:17` `rust/kernel/module_param.rs:83:17` Added `// SAFETY` docs to `fn get_param` `rust/kernel/module_param.rs:104:9` `rust/kernel/module_param.rs:108:9` Added `// SAFETY` docs to `fn free` `rust/kernel/module_param.rs:124:9` Signed-off-by: Dee-Jay Logozzo <git@djl.id.au>
Contributes to Rust-for-Linux#351 Added `// SAFETY` docs to `fn proc_handler` `rust/kernel/sysctl.rs:97:1` `rust/kernel/sysctl.rs:113:5` `rust/kernel/sysctl.rs:115:9` `rust/kernel/sysctl.rs:120:5` `rust/kernel/sysctl.rs:124:5` `rust/kernel/sysctl.rs:136:5` `rust/kernel/sysctl.rs:138:5` Added `// SAFETY` docs to `fn init_lock` `rust/kernel/sync/mutex.rs:85:9` Added `// SAFETY` docs to `fn init_lock` `rust/kernel/sync/spinlock.rs:144:9` Added `// SAFETY` docs to `fn init` `rust/kernel/sync/condvar.rs:135:9` Added `// SAFETY` docs to `fn read` `rust/kernel/pages.rs:96:9` Added `// SAFETY` docs to `fn write` `rust/kernel/pages.rs:125:9` Added `// SAFETY` docs to `fn rust_fmt_argument` `rust/kernel/print.rs:17:1` `rust/kernel/print.rs:62:5` Added `// SAFETY` docs to `fn set_param` `rust/kernel/module_param.rs:63:5` `rust/kernel/module_param.rs:74:13` `rust/kernel/module_param.rs:80:17` `rust/kernel/module_param.rs:83:17` Added `// SAFETY` docs to `fn get_param` `rust/kernel/module_param.rs:104:9` `rust/kernel/module_param.rs:108:9` Added `// SAFETY` docs to `fn free` `rust/kernel/module_param.rs:124:9` Signed-off-by: Dee-Jay Logozzo <git@djl.id.au>
Contributes to Rust-for-Linux#351 Added `// SAFETY` docs to `fn proc_handler` `rust/kernel/sysctl.rs:97:1` `rust/kernel/sysctl.rs:113:5` `rust/kernel/sysctl.rs:115:9` `rust/kernel/sysctl.rs:120:5` `rust/kernel/sysctl.rs:124:5` `rust/kernel/sysctl.rs:136:5` `rust/kernel/sysctl.rs:138:5` Added `// SAFETY` docs to `fn init_lock` `rust/kernel/sync/mutex.rs:85:9` Added `// SAFETY` docs to `fn init_lock` `rust/kernel/sync/spinlock.rs:144:9` Added `// SAFETY` docs to `fn init` `rust/kernel/sync/condvar.rs:135:9` Added `// SAFETY` docs to `fn read` `rust/kernel/pages.rs:96:9` Added `// SAFETY` docs to `fn write` `rust/kernel/pages.rs:125:9` Added `// SAFETY` docs to `fn rust_fmt_argument` `rust/kernel/print.rs:17:1` `rust/kernel/print.rs:62:5` Added `// SAFETY` docs to `fn set_param` `rust/kernel/module_param.rs:63:5` `rust/kernel/module_param.rs:74:13` `rust/kernel/module_param.rs:80:17` `rust/kernel/module_param.rs:83:17` Added `// SAFETY` docs to `fn get_param` `rust/kernel/module_param.rs:104:9` `rust/kernel/module_param.rs:108:9` Added `// SAFETY` docs to `fn free` `rust/kernel/module_param.rs:124:9` Signed-off-by: Dee-Jay Logozzo <git@djl.id.au>
// SAFETY
comments// SAFETY
comments
// SAFETY
comments// SAFETY
comments
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: #351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: #351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The function rust_fmt_argument derefernces a c_void pointer, and thus it needs an unsafe block. The safety comment for that block was missing. Part of Rust-for-Linux#351. Signed-off-by: Konstantin Andrikopoulos <kernel@mandragore.io>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux/linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Don't know how if it's on the easy side or not, but I would like to handle the safety comments in |
Of course -- please feel free to send the cleanups to the LKML directly. |
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux/linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux/linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Add missing safety comments for the implementation of the unsafe traits WorkItemPointer and RawWorkItem for Arc<T> in workqueue.rs Link: Rust-for-Linux#351. Signed-off-by: Konstantin Andrikopoulos <kernel@mandragore.io> Co-developed-by: Vangelis Mamalakis <mamalakis@google.com> Signed-off-by: Vangelis Mamalakis <mamalakis@google.com> Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Add missing safety comments for the implementation of the unsafe traits WorkItemPointer and RawWorkItem for Arc<T> in workqueue.rs Link: Rust-for-Linux#351. Co-developed-by: Vangelis Mamalakis <mamalakis@google.com> Signed-off-by: Vangelis Mamalakis <mamalakis@google.com> Suggested-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Konstantin Andrikopoulos <kernel@mandragore.io>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux/linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit db4f72c904cb116e2bf56afdd67fc5167a607a7b) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux/linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit db4f72c904cb116e2bf56afdd67fc5167a607a7b) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux/linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit db4f72c904cb116e2bf56afdd67fc5167a607a7b) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux/linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit db4f72c904cb116e2bf56afdd67fc5167a607a7b) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux/linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit db4f72c904cb116e2bf56afdd67fc5167a607a7b) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add missing safety comments for the implementation of the unsafe traits WorkItemPointer and RawWorkItem for Arc<T> in workqueue.rs Link: Rust-for-Linux#351. Co-developed-by: Vangelis Mamalakis <mamalakis@google.com> Signed-off-by: Vangelis Mamalakis <mamalakis@google.com> Suggested-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Konstantin Andrikopoulos <kernel@mandragore.io> Signed-off-by: Tejun Heo <tj@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux/linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux/linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux/linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux/linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux/linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux/linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit db4f72c904cb116e2bf56afdd67fc5167a607a7b) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Checking that we are not missing any `// SAFETY` comments in our `unsafe` blocks is something we have wanted to do for a long time, as well as cleaning up the remaining cases that were not documented [1]. Back when Rust for Linux started, this was something that could have been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0, Clippy implemented the `undocumented_unsafe_blocks` lint [2]. Even though the lint has a few false positives, e.g. in some cases where attributes appear between the comment and the `unsafe` block [3], there are workarounds and the lint seems quite usable already. Thus enable the lint now. We still have a few cases to clean up, so just allow those for the moment by writing a `TODO` comment -- some of those may be good candidates for new contributors. Link: Rust-for-Linux/linux#351 [1] Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2] Link: rust-lang/rust-clippy#13189 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Add missing safety comments for the implementation of the unsafe traits WorkItemPointer and RawWorkItem for Arc<T> in workqueue.rs Link: Rust-for-Linux#351. Co-developed-by: Vangelis Mamalakis <mamalakis@google.com> Signed-off-by: Vangelis Mamalakis <mamalakis@google.com> Suggested-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Konstantin Andrikopoulos <kernel@mandragore.io> Signed-off-by: Tejun Heo <tj@kernel.org>
Add missing safety comments for the implementation of the unsafe traits WorkItemPointer and RawWorkItem for Arc<T> in workqueue.rs Link: Rust-for-Linux#351. Co-developed-by: Vangelis Mamalakis <mamalakis@google.com> Signed-off-by: Vangelis Mamalakis <mamalakis@google.com> Suggested-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Konstantin Andrikopoulos <kernel@mandragore.io> Signed-off-by: Tejun Heo <tj@kernel.org>
We do not allow new
unsafe
comments to enter the codebase without a// SAFETY
comment. Nowadays, we use Clippy'sundocumented_unsafe_blocks
to check for that. However, some// SAFETY: TODO.
comments remain (please see therust-next
branch). The issue is about cleaning those up.It is not needed to fix all the comments at once (in fact, a given area/module/file should be cleaned independently), so this is a set of "good first issues". Please note that some of the comments may be easier or harder to figure out than others.
This requires submitting a proper patch to the LKML and the Rust for Linux mailing list. Please recall to test your changes (including generating the documentation if changed, running the Rust doctests if changed, etc.), to use a proper title for the commit, to sign your commit under the Developer's Certificate of Origin and to add a
Suggested-by:
tag and aLink:
tag to this issue. Please see https://rust-for-linux.com/contributing for details.The text was updated successfully, but these errors were encountered: