Re: Panic in tmpfs

[Michael Plass <mfpnb%plass-family.net@localhost>]

On Jun 9, 2016, at 10:59 PM, Paul Goyette wrote:

> On Fri, 10 Jun 2016, coypu%SDF.ORG@localhost wrote:
> 
>> On Thu, Jun 09, 2016 at 08:07:57PM -0700, Michael Plass wrote:
>>> Does this ring a bell with anybody? The only similar panic on gnats that I was able to
>>> find was closed in 2011. But I've had trouble finding things in gnats before.
>>> 
>> 
>> PR/50381
>> 
>> http://gnats.netbsd.org/50381
> 
> This PR was fixed more than 6 months ago, and pullups done to -7 and -7-0 branches.
> 
> The uname looks like Michael's kernel was built in February 2016, but from which-date sources?
> 
> 
> +------------------+--------------------------+------------------------+
> | Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
> | (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
> | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
> +------------------+--------------------------+------------------------+
> 
> 

It was built from the 7.0 release, so it would predate the 7.0.1 branch.

I've been looking at the code some more, and I think the problem I ran into is
different than PR/50381. That one dealt with filling up the volume with data, but
mine is failing when attempting to make a directory that won't fit.
For a newly minted directory, the node's tn_links field is 1 (the extra
link count for '.'), and the error paths in tmpfs_construct_node don't adjust
for this before trying to free the node.

I also figured out why the /var/shm test didn't fail for me. I think it
ran out of space trying to allocate the node, so there was nothing to clean up.
Changing the test to use a longer file name (143 bytes) did panic.

I have a fairly recent -current image that I can try this on. I'll do that.

Thanks,
- Michael