Skip to content

Consider how to scale the bindings #182

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

Closed
ojeda opened this issue Apr 12, 2021 · 1 comment
Closed

Consider how to scale the bindings #182

ojeda opened this issue Apr 12, 2021 · 1 comment
Labels
• kbuild Related to building the kernel, `make`, `Kbuild`, `Kconfig` options...

Comments

@ojeda
Copy link
Member

ojeda commented Apr 12, 2021

Currently we only generate bindings for a fixed set of headers in rust/. However, as Rust abstractions grow, we will likely need to expand the set of headers greatly, which is unlikely to scale well in a single file.

Please note that, in general, we do not want Rust modules to be calling the C side directly (i.e. bypassing the abstractions). Thus allowing other modules to generate bindings at will may be opening the doors too much. In fact, ideally, we could enforce no bindings calls outside rust/.

If we can keep that approach, then as Rust abstractions grow, we may want to split rust/kernel/ into different crates, each declaring the set of bindings they need in a header etc. (and then either passing them all at once to bindgen or perhaps separately).

@ojeda ojeda added • kbuild Related to building the kernel, `make`, `Kbuild`, `Kconfig` options... prio: normal labels Apr 12, 2021
@ojeda ojeda removed the prio: low label Feb 17, 2023
@ojeda
Copy link
Member Author

ojeda commented Oct 29, 2024

Closing -- splitting the helpers was already done, and we will also split the crates.

@ojeda ojeda closed this as completed Oct 29, 2024
onestacked pushed a commit to onestacked/linux that referenced this issue Apr 13, 2025
Commit 8284066 ("ublk: grab request reference when the request is handled
by userspace") doesn't grab request reference in case of recovery reissue.
Then the request can be requeued & re-dispatch & failed when canceling
uring command.

If it is one zc request, the request can be freed before io_uring
returns the zc buffer back, then cause kernel panic:

[  126.773061] BUG: kernel NULL pointer dereference, address: 00000000000000c8
[  126.773657] #PF: supervisor read access in kernel mode
[  126.774052] #PF: error_code(0x0000) - not-present page
[  126.774455] PGD 0 P4D 0
[  126.774698] Oops: Oops: 0000 [Rust-for-Linux#1] SMP NOPTI
[  126.775034] CPU: 13 UID: 0 PID: 1612 Comm: kworker/u64:55 Not tainted 6.14.0_blk+ Rust-for-Linux#182 PREEMPT(full)
[  126.775676] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014
[  126.776275] Workqueue: iou_exit io_ring_exit_work
[  126.776651] RIP: 0010:ublk_io_release+0x14/0x130 [ublk_drv]

Fixes it by always grabbing request reference for aborting the request.

Reported-by: Caleb Sander Mateos <csander@purestorage.com>
Closes: https://lore.kernel.org/linux-block/CADUfDZodKfOGUeWrnAxcZiLT+puaZX8jDHoj_sfHZCOZwhzz6A@mail.gmail.com/
Fixes: 8284066 ("ublk: grab request reference when the request is handled by userspace")
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20250409011444.2142010-2-ming.lei@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
• kbuild Related to building the kernel, `make`, `Kbuild`, `Kconfig` options...
Development

No branches or pull requests

1 participant