-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Race condition when printing in interrupt handlers #831
Comments
Thanks for reporting and sorry for the late reply! I think we used to get this right, but probably something changed in our writer implementation or in the formatting code generated by the compiler. The best approach to fix this would probably be to implement the fmt::Write trait directly for the Mutex-wrapped writer and only lock it in the I'm planning some larger updates to the printing code soon to switch from the text-based buffer to a pixel-based framebuffer soon. I will keep this issue in mind and ensure that the new code won't have this problem. |
Hi I tried to implement the write on Mutex-wrapped but I'm not sure what's the problem a bit of help would be relly helpfull . For this code
I get the following error
Here is the implementation
|
@nicolae536 What is your |
@bjorn3 I updated the post. I posted the wrong file first time. |
impl Deref for WrappedWriter {
type Target = WrappedWriter;
fn deref(&self) -> &Self::Target {
return self;
}
} It is not valid for a type to deref to itself. |
No worries! This sounds good, thank you 👍 |
@bjorn3 I also tried to change it like you mention but if I change to deref to
|
You have to call |
First of all this blog post series is pure joy. Thank you very much for creating and maintaining this!
During the paging introduction chapter I noticed a race condition. It can occur when printing (or panicking for that matter) inside an interrupt handler (for example page or double fault handlers do exactly that). The race is triggered for example when a double fault occurs during printing, but the
WRITER
instance is already locked:I fixed it for myself by creating a
print_panic
function that does directly write to the vga buffer, not respecting theWRITER
(which is then used inside the panic handler instead of the normalprintln
macro and as a consequence onlypanic!
orprint_panic!
is allowed inside interrupt handlers by "convention"). This fixes the problem for me, but it does not seem ideal and maybe introduces new problems? Is there a better solution?Is it even worth fixing? I'm not sure. It is a detail. But then again it is a bug and more than that readers could learn something if this case is explicitly handled in the blog post (I'm willing to create a pull request).
The text was updated successfully, but these errors were encountered: