Simple Rust driver that touches real hardware: PR 6 #435
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
July 8, 2021 12:07
Before proceeding with the trickier aspects of platdev (and the driver model in general), add a `PlatformDriver` callback which accesses its `PlatData` as a `Borrowed`. The majority of `bindings::platform_driver` callbacks access their platform data by reference. So it would be prudent to have at least one callback that demonstrates this behaviour. We pick `shutdown` because it is trivial to implement, and easy to trigger by executing `shutdown -P now` in the shell. Signed-off-by: Sven Van Asbroeck <[email protected]>
Add per-device context, which simply contains a single zero `u32`. It gets wrapped inside a `Ref<>` so it can be passed to multiple `FileOpener`s. Note that it's not protected by a lock, so the context inside the `Ref` is immutable. Use the per-device context to demonstrate that: - it can be accessed from inside the `FileOpener` (by returning the zero `u32` on `read`) - it can be accessed as a `Borrowed` value from inside `shutdown` Signed-off-by: Sven Van Asbroeck <[email protected]>
|
@ojeda @wedsonaf I noticed that there has been a lot of ongoing LKML (or ksummit?) discussion re. "real driver", "devm", "kernel and rust lifetimes", etc. With that in mind, I'd appreciate if you could let me know whether the goal of these PRs is still worth pursuing, needs adjustment, or has been superseded by advice or events. Just so we can all use our valuable time wisely. |
|
@TheSven73 Definitely. The discussion is still going (I just sent a message there), so let's see what they say about letting us come up with our own APIs to manage objects on the Rust side. Because if we can do that, more options get unlocked for us. |
|
"parked" until we have more LKML feedback, and updated strategy. |
ojeda
pushed a commit
that referenced
this pull request
Dec 20, 2021
smc_lgr_cleanup_early() meant to delete the link group from the link group list, but it deleted the list head by mistake. This may cause memory corruption since we didn't remove the real link group from the list and later memseted the link group structure. We got a list corruption panic when testing: [ 231.277259] list_del corruption. prev->next should be ffff8881398a8000, but was 0000000000000000 [ 231.278222] ------------[ cut here ]------------ [ 231.278726] kernel BUG at lib/list_debug.c:53! [ 231.279326] invalid opcode: 0000 [#1] SMP NOPTI [ 231.279803] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.46+ #435 [ 231.280466] Hardware name: Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014 [ 231.281248] Workqueue: events smc_link_down_work [ 231.281732] RIP: 0010:__list_del_entry_valid+0x70/0x90 [ 231.282258] Code: 4c 60 82 e8 7d cc 6a 00 0f 0b 48 89 fe 48 c7 c7 88 4c 60 82 e8 6c cc 6a 00 0f 0b 48 89 fe 48 c7 c7 c0 4c 60 82 e8 5b cc 6a 00 <0f> 0b 48 89 fe 48 c7 c7 00 4d 60 82 e8 4a cc 6a 00 0f 0b cc cc cc [ 231.284146] RSP: 0018:ffffc90000033d58 EFLAGS: 00010292 [ 231.284685] RAX: 0000000000000054 RBX: ffff8881398a8000 RCX: 0000000000000000 [ 231.285415] RDX: 0000000000000001 RSI: ffff88813bc18040 RDI: ffff88813bc18040 [ 231.286141] RBP: ffffffff8305ad40 R08: 0000000000000003 R09: 0000000000000001 [ 231.286873] R10: ffffffff82803da0 R11: ffffc90000033b90 R12: 0000000000000001 [ 231.287606] R13: 0000000000000000 R14: ffff8881398a8000 R15: 0000000000000003 [ 231.288337] FS: 0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 [ 231.289160] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 231.289754] CR2: 0000000000e72058 CR3: 000000010fa96006 CR4: 00000000003706f0 [ 231.290485] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 231.291211] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 231.291940] Call Trace: [ 231.292211] smc_lgr_terminate_sched+0x53/0xa0 [ 231.292677] smc_switch_conns+0x75/0x6b0 [ 231.293085] ? update_load_avg+0x1a6/0x590 [ 231.293517] ? ttwu_do_wakeup+0x17/0x150 [ 231.293907] ? update_load_avg+0x1a6/0x590 [ 231.294317] ? newidle_balance+0xca/0x3d0 [ 231.294716] smcr_link_down+0x50/0x1a0 [ 231.295090] ? __wake_up_common_lock+0x77/0x90 [ 231.295534] smc_link_down_work+0x46/0x60 [ 231.295933] process_one_work+0x18b/0x350 Fixes: a0a62ee ("net/smc: separate locks for SMCD and SMCR link group lists") Signed-off-by: Dust Li <[email protected]> Acked-by: Karsten Graul <[email protected]> Reviewed-by: Tony Lu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Simple Rust driver that touches real h/w: step 6
@alex and @ojeda suggested that #254 should be split into smaller PRs, so they can be reviewed and merged individually.
Roadmap:
DrvDataasBorrowed(you are here)DrvDatareferences inPlatformDrivertrait