Re: kern/47739: tmpfs panic: kernel diagnostic assertion "(node)->tn_spec.tn_dir.tn_readdir_lastp == NULL..."

[David Laight <david%l8s.co.uk@localhost>]

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

From: David Laight <david%l8s.co.uk@localhost>
To: David Holland <dholland-bugs%netbsd.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: kern/47739: tmpfs panic: kernel diagnostic assertion 
"(node)->tn_spec.tn_dir.tn_readdir_lastp == NULL..."
Date: Wed, 9 Oct 2013 21:27:38 +0100

 On Mon, Oct 07, 2013 at 07:42:23AM +0000, David Holland wrote:
 > On Thu, Aug 08, 2013 at 08:30:01PM +0000, Mindaugas Rasiukevicius wrote:
 >  >  >  Can someone please take a look?
 > 
 > almost certainly the same as 47480 (and 41068)
 > 
 >  >  >   Thomas
 >  >  
 >  >  Most likely this is due to tmpfs_dircookie() truncation here:
 >  >  
 >  >  http://nxr.netbsd.org/source/xref/src/sys/fs/tmpfs/tmpfs.h#88
 >  >  
 >  >  It is wrong and there are other PRs because of it.  Thomas, you can test
 >  >  this by replacing the function body with the following:
 >  >  
 >  >   return (off_t)(uintptr_t)de;
 >  >  
 >  >  This breaks linux32 compat, but we really just need to decide how we want
 >  >  to fix it (it would be good to avoid penalising the native code, but 
 > better
 >  >  to penalise than fail).
 > 
 > Four and a half years ago (in PR 41068) I asked why tmpfs does this
 > nonsense instead of just assigning sequence numbers to each node.
 > Nobody has ever managed to come up with a coherent justification, just
 > FUD.
 
 If it assigned sequence numbers it would have to check for already used
 values once it had created 2^32 entries (assuming it needs to generate
 32bit offsets).
 
 Something based on the algorithm used to look up process ids might be
 better.
 
        David
 
 -- 
 David Laight: david%l8s.co.uk@localhost