-
Notifications
You must be signed in to change notification settings - Fork 132
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
Panic on accessing MTD file descriptor after unbinding aspeed-smc driver #209
Comments
Unfortunately, the platform code ignores the returned value of the remove handler. |
Yeah, there's no failure path for the unbind operation...commit e5e1c20 acknowledges that the driver core ignores the remove operation's return value, but it doesn't sound like there's any movement toward that changing, and if anything sounds like things are going the opposite direction ("The right thing to do would be to make struct platform_driver::remove() return void."). I'm not sure what the reasoning is there; there doesn't appear to have been any further discussion at the time on the list: https://lore.kernel.org/all/20210207211537.19992-1-uwe@kleine-koenig.org/. So it seems like the intended model is "remove() operations must succeed", but that leaves us in a bit of an awkward situation. After reading through some code, it looks like this particular problem stems (more immediately) from the aspeed-smc driver allocating the Thinking out loud:
|
I have another experimental Aspeed SMC driver using
|
Interesting...though it looks like in that case the panic happened during the unbind, instead of on an FD access after it? |
The following script triggers a kernel panic:
dmesg output:
I'm looking into possible fixes, but figured I'd file it here in case anyone else has any input (and so it doesn't get lost/forgotten).
The text was updated successfully, but these errors were encountered: