[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/47739: tmpfs panic: kernel diagnostic assertion "(node)->tn_spec.tn_dir.tn_readdir_lastp == NULL..."
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>
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
> > 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
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
Something based on the algorithm used to look up process ids might be
David Laight: david%l8s.co.uk@localhost
Main Index |
Thread Index |