Date: Wed, 1 Nov 2006 21:08:19 +0100 From: Ulrich Spoerlein <uspoerlein@gmail.com> To: Kris Kennaway <kris@obsecurity.org> Cc: stable@freebsd.org Subject: Re: panic: vfs_getopt: caller passed 'opts' as NULL Message-ID: <20061101200819.GB1522@roadrunner.q.local> In-Reply-To: <20061101175428.GA33982@xor.obsecurity.org> References: <7ad7ddd90610300741k5789f64j8f410b6e866b99ee@mail.gmail.com> <20061030224935.GA95120@xor.obsecurity.org> <7ad7ddd90610302348j6b7aabc7vc0a89e1e95d8fd27@mail.gmail.com> <20061031184150.GA27161@xor.obsecurity.org> <7ad7ddd90611010257o75546455p7da194b17037f8ed@mail.gmail.com> <20061101175428.GA33982@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > > Nullfs seems more fragile than I initially thought ... > > It's just that compiling in the extra debugging (it might be > DEBUG_LOCKS or DEBUG_VFS_LOCKS, I forget which), causes the sizes of > structures to change, so when the module tries to fondle the structure > at a certain offset thinking it's accessing a certain field, it's > really fondling something else entirely and the kernel gets a nasty > surprise and panics. It is DEBUG_LOCKS. The DEBUG_VFS_LOCKS macro only enables additional code at runtime, it does not alter the ABI. Ironically, it is even documented in conf/NOTES. For the future, I have to remember that nullfs is a module. Ulrich Spoerlein -- A: Yes. >Q: Are you sure? > >A: Because it reverses the logical flow of conversation. > >>Q: Why is top posting frowned upon?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061101200819.GB1522>