Chris's Wiki :: blog/linux/Ubuntu1804OddKernelPanic Commentshttps://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu1804OddKernelPanic?atomcommentsDWiki2019-05-15T19:01:20ZRecent comments in Chris's Wiki :: blog/linux/Ubuntu1804OddKernelPanic.By Chris Siebenmann on /blog/linux/Ubuntu1804OddKernelPanictag:CSpace:blog/linux/Ubuntu1804OddKernelPanic:e96bbc29788dbfc359029b9c42392b5e667deb93Chris Siebenmann<div class="wikitext"><p>The NULL being the <code>inode</code> argument would make the call path
make more sense, too. The <code>path</code> is touched frequently on the
call path, but <code>inode</code> is only retrieved at the last moment from
path->dentry. This does leave open the question of how a valid path got
a null <code>dentry->d_inode</code>, but maybe that can happen with synthetic
filesystems if they're updating themselves at the wrong time.</p>
<p>Thanks!</p>
</div>2019-05-15T19:01:20ZBy Alan on /blog/linux/Ubuntu1804OddKernelPanictag:CSpace:blog/linux/Ubuntu1804OddKernelPanic:85bef6bb368751a2a3ac85260a08c98c3418830bAlanhttps://twitter.com/sourcejedi<div class="wikitext"><p>0x0c = 12. `struct path` is just a pair of pointers, so neither field has an offset of 12. But it <em>does</em> match inode->i_flags. Therefore the NULL pointer is probably from the inode argument, not the path argument.</p>
</div>2019-05-15T17:22:10Z