Re: kern/47480: tmpfs panic: panic: kernel diagnostic assertion "cookie != TMPFS_DIRCOOKIE_DOT" failed

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/47480; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/47480: tmpfs panic: panic: kernel diagnostic assertion
 "cookie != TMPFS_DIRCOOKIE_DOT" failed
Date: Wed, 23 Jan 2013 09:40:54 +0000

 On Mon, Jan 21, 2013 at 01:00:01PM +0000, Thomas Klausner wrote:
  > This actually looks like two interspersed strings on might be:
  > 
  > file "/archive/cvs/src/sys/[f?]s/tmpfs/tmpfs.h [4936?]
  > Line 4930 of that file here is
  >         KASSERT(cookie != TMPFS_DIRCOOKIE_DOT);
 
 tmpfs.h doesn't have anywhere near that many lines. It's on line 93,
 though.
 
  > The other might be:
  > [W?]ARNING: SPL NOT LOWERED ON SY[S?]CALL EXIT
 
 As I was saying elsewhere, it's rather interesting that these should
 come up together.
 
 Does leaving the kernel while holding a spinlock cause this warning or
 some other one? (In other words, are we looking specifically for a spl
 leak, which there probably aren't too many opportunities for, or is it
 just a dangling lock?)
 
 I was going to suggest that somewhere there's a broken error path that
 both leaks spl (or a spinlock) and also corrupts something, but it
 doesn't look that simple. There are very few places where this code is
 called and most of them are using a pointer popped directly off a
 tailq that is checked for NULL, so it's very unlikely that it's that
 unless you have major memory corruption.
 
 On further review I think this is the same as kern/41068, which I
 believed at the time to be caused by getting a 64-bit tmpfs_dirent
 pointer whose lower 32 bits are all 0.
 
 (I still don't understand why the simple rework I suggested in
 kern/41068 won't do.)
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost