On Thu, Nov 10, 2022 at 08:14:01PM -0500, Ahelenia Ziemiańska wrote: > We have largely moved away from this approach, and we have better > debugging tooling nowadays: kill it. I still haven't received a response to my earlier email asking what better debug tooling you are talking about. I gave an example of an older bug, which has been fixed, where a Coda inode accidentally ending up in ext4 through an mmap path. This ended up scribbling over a spinlock in the coda_inode_info data which resulted into pretty random system lockups. This was actually quite hard to track down because there is no check that `file_inode(vma->vm_file)` actually returns the inode of another file system. So I'd be interesting what this tooling is or how it can be used to better catch/identify such cases. So I actually like this type of magic because it can potentially catch some cases that should never happen. We could rename it to from MAGIC to ASSERT, we don't remove asserts from code because of better debug tooling. Those random 4 bytes in a Coda internal structure are not in a hot path. Jan
