4 ms·

Screwing up my page tables

47 points by ingve 3y ago

sterlind 3y ago
> Hmm, I’m not familiar with cdqe. A quick search reveals that it sign-extends the lower 4 bytes into the full 8 bytes. Ah ha! A flash of insight illuminates my grasping waddles. Could it be that kmalloc() is implicitly defined at the call site, so the compiler assumes the return type is a 32-bit int, chucking out the top half of the pointer value? This really shows the glory, and the horror, of low-level systems programming. You make a seemingly-simple change, which surfaces a bug, which leads to gruesome crashes - the kind where the black box ends up in pieces - which you finally somehow trace back to an odd assembly instruction, which happened because you forgot to include a header so the C compiler simply hallucinated a function prototype! Because header files weren't free in the '70s, apparently! It requires the kind of mind that can diagnose a leaky head gasket from a customer pantomiming goosh-goosh sounds.
- codyd51 3y ago
  Hi, author here! Haha, yes, you’ve summed it up pretty well. I was unsure whether to write this post as, in one sense, it’s detective work in which I’m the investigator, and a slightly younger and more sloppy version of myself is the culprit. As you said, though, there's also more to it: the system takes on a life of its own, with different parts of the stack interacting in unexpected and complex ways, in an environment that doesn’t give me much help to write things correctly (and occasionally presents footguns on a silver platter). It’s really gratifying to see people reading and identifying with it, and I’m also extending my thanks to the user who posted this to HN!
turtledragonfly 3y ago
I like these war stories — the worst bugs aren't solved by tools or tests, but by semi-desperate flashes of insight after you've been tearing your hear out for hours. It's great when the very foundations of what you're used to trusting (eg: an allocator, the kernel, your compiler, etc) are where the bugs lie.
- codyd51 3y ago
  Thank you! Indeed, more than once over the course of introducing this new PMM I felt a sense of desperation as bugs surfaced due to an “I don’t know what I changed” change. Often, the answer is “nothing special”, and extremely minor pieces of happenstance (such as the exact layout of address space requested by the kernel ELF) lead to something breaking way down the ladder. It's really nice to hear that you enjoyed it!
cperciva 3y ago
If you enjoyed this, you might enjoy my work porting FreeBSD to Firecracker. I gave a talk at BSDCan which will be on YouTube sometime soon, and also wrote it up for the upcoming edition of the FreeBSD Journal.
deleted 3y ago
[deleted]

47 points by ingve 3y ago

> Hmm, I’m not familiar with cdqe. A quick search reveals that it sign-extends the lower 4 bytes into the full 8 bytes. Ah ha! A flash of insight illuminates my grasping waddles. Could it be that kmalloc() is implicitly defined at the call site, so the compiler assumes the return type is a 32-bit int, chucking out the top half of the pointer value? This really shows the glory, and the horror, of low-level systems programming. You make a seemingly-simple change, which surfaces a bug, which leads to gruesome crashes - the kind where the black box ends up in pieces - which you finally somehow trace back to an odd assembly instruction, which happened because you forgot to include a header so the C compiler simply hallucinated a function prototype! Because header files weren't free in the '70s, apparently! It requires the kind of mind that can diagnose a leaky head gasket from a customer pantomiming goosh-goosh sounds.

codyd51 3y ago
Hi, author here! Haha, yes, you’ve summed it up pretty well. I was unsure whether to write this post as, in one sense, it’s detective work in which I’m the investigator, and a slightly younger and more sloppy version of myself is the culprit. As you said, though, there's also more to it: the system takes on a life of its own, with different parts of the stack interacting in unexpected and complex ways, in an environment that doesn’t give me much help to write things correctly (and occasionally presents footguns on a silver platter). It’s really gratifying to see people reading and identifying with it, and I’m also extending my thanks to the user who posted this to HN!

turtledragonfly 3y ago

I like these war stories — the worst bugs aren't solved by tools or tests, but by semi-desperate flashes of insight after you've been tearing your hear out for hours. It's great when the very foundations of what you're used to trusting (eg: an allocator, the kernel, your compiler, etc) are where the bugs lie.

codyd51 3y ago
Thank you! Indeed, more than once over the course of introducing this new PMM I felt a sense of desperation as bugs surfaced due to an “I don’t know what I changed” change. Often, the answer is “nothing special”, and extremely minor pieces of happenstance (such as the exact layout of address space requested by the kernel ELF) lead to something breaking way down the ladder. It's really nice to hear that you enjoyed it!

cperciva 3y ago

If you enjoyed this, you might enjoy my work porting FreeBSD to Firecracker. I gave a talk at BSDCan which will be on YouTube sometime soon, and also wrote it up for the upcoming edition of the FreeBSD Journal.

deleted 3y ago

[deleted]