On Tue, Oct 26, 2010 at 08:44:37AM -0400, erik quanstrom wrote: > On Mon Oct 25 22:03:53 EDT 2010, [email protected] wrote: > > > hm... wouldnt it just crash if mh->mount is nil? > > > > perhaps you are reading the diff backwards? it used to > crash when mh->mount was nil. leading to a lock loop. > i added the test to see that mh->mount != nil after the > rlock on mh->lock is acquired. otherwise, there is a race > with unmount which can make mh->mount nil while we're running. > I was hoping you'd follow up on that, I needed a seed message and my mailbox has recently overflowed :-(
I'm curious what you call "crash" in this case and I think Cinap is too. Basically, exactly what happens in the situation when a nil pointer is dereferenced in the kernel? How does the kernel survive and slip into a locked situation? Yes, yes, I know I could read the sources, but that's a skill I'm a little short on. > our newer faster processors with more cores were making > this event likely enough that a few receipies would crash > the machine within 5 minutes. > I really appreciate the fix, it certainly had the desired effect. ++L
