Re: Panic in tmpfs
On Fri, 10 Jun 2016, Michael Plass wrote: On Jun 9, 2016, at 11:39 PM, Michael Plass wrote: I have a fairly recent -current image that I can try this on. I'll do that. OK, it looks like I was wrong, it is fixed with PR/50381. I couldn't make the problem happen on the -current image (source date Wed May 18 11:28:44 2016 +) Great - thanks for checking! +--+--++ | 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 | +--+--++
Re: Panic in tmpfs
On Jun 9, 2016, at 11:39 PM, Michael Plass wrote: > I have a fairly recent -current image that I can try this on. I'll do that. OK, it looks like I was wrong, it is fixed with PR/50381. I couldn't make the problem happen on the -current image (source date Wed May 18 11:28:44 2016 +) Thanks! - Michael
Re: Panic in tmpfs
On Jun 9, 2016, at 10:59 PM, Paul Goyette wrote: > On Fri, 10 Jun 2016, co...@sdf.org 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
Re: Panic in tmpfs
On Fri, 10 Jun 2016, co...@sdf.org 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 | +--+--++
Re: Panic in tmpfs
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 Sometimes, I use Google search with site:mail-index.netbsd.org, for better queries. This one I remembered frmo 7.0.1 release notes. Thanks!
Panic in tmpfs
I ran into this panic yesterday:
panic: kernel diagnostic assertion "node->tn_links == 0" failed: file
"/home/michael/NetBSD-7.0/build/usr/src/sys/fs/tmpfs/tmpfs_subr.c", line 261
db{3}> bt
0xb384dcec: netbsd:vpanic+0xc
0xb384dd04: netbsd:__udivmoddi4
0xb384dd3c: netbsd:tmpfs_free_node+0x1ac
0xb384dd94: netbsd:tmpfs_construct_node+0x22c
0xb384ddbc: netbsd:tmpfs_mkdir+0x48
0xb384ddfc: netbsd:VOP_MKDIR+0x4c
0xb384df0c: netbsd:do_sys_mkdirat.constprop.4+0x120
0xb384df7c: netbsd:syscall+0x88
0xb384dfac: netbsd:swi_handler+0x98
db{3}> ps
It turns out to be easy to reproduce - just fill the tmpfs file system
and then try to create directories until it breaks.
This is on a NetBSD-7.0 RPI2 system patched
with http://www.netbsd.org/~skrll/usb.softint.diff:
NetBSD mipi 7.0 NetBSD 7.0 (RPI2_NET) #0: Sat Feb 6 23:07:24 PST 2016
mich...@home.plass-family.net:/home/michael/NetBSD-7.0/build/usr/src/sys/arch/evbarm/compile/obj/RPI2_NET
evbarm
I have this in my /etc/fstab:
tmpfs /tmptmpfs rw,-sram/2
mipi$ cd /tmp
mipi$ dd if=/dev/zero of=junk
dd: junk: No space left on device
966641+0 records in
966640+0 records out
494919680 bytes transferred in 32.255 secs (15343967 bytes/sec)
mipi$ jot 100 | while read i && mkdir -p $i; do printf '%s ' $i >&2; done
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
30 31 32 33 34
(panics here)
Interestingly, an attempt to reproduce it using /var/shm, which is mounted with
-sram%10,
did not end in panic.
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.
Thanks.
- Michael
