Re: ffs_newvnode: inode has non zero blocks

[Jaromír Doleček <jaromir.dolecek%gmail.com@localhost>]

There was recenly change a change in FFS in the general area for
WAPBL. Can you try attached patch and check if following KASSERT()
triggers?

2016-11-02 18:39 GMT+01:00 Andreas Gustafsson <gson%gson.org@localhost>:
> coypu%SDF.ORG@localhost wrote:
>> I'm pretty 'abusive' to my machine. unsurprisingly, I've managed to accumulate a problem:
>>
>>   ffs_newvnode: ino=20681997 on /: gen 5ae8a721/5ae8a721 has non zero blocks 980 or size 0
>>   panic: ffs_newvnode: dirty filesystem?
>
> The TNF sparc testbed recently started panicing with a similar error in
> every test run:
>
>   sbin/resize_ffs/t_grow_swapped (445/663): 4 test cases
>       grow_16M_v0_65536: ffs_newvnode: ino=45826 on /: gen 65327e67/65327e67 has non zero blocks 180 or size 0
>   panic: ffs_newvnode: dirty filesystem?
>   cpu0: Begin traceback...
>   0x0(0xf04010b8, 0xf4538a50, 0xf04a3800, 0xf04a4400, 0xf04a45c0, 0x104) at netbsd:panic+0x20
>   panic(0xf04010b8, 0xf03c39a0, 0x0, 0xb302, 0xf07578d4, 0xf047e000) at netbsd:ffs_newvnode+0x444
>   ffs_newvnode(0xf0730000, 0xf0970328, 0x81a4, 0xf4538cb0, 0xf069cb28, 0xf0984810) at netbsd:vcache_new+0x5c
>   vcache_new(0xf0730000, 0xf0970328, 0xf4538cb0, 0xf069cb28, 0xf4538b74, 0x0) at netbsd:ufs_makeinode+0x14
>   ufs_makeinode(0xf4538cb0, 0xf0970328, 0xf096ef2c, 0xf4538dcc, 0xf4538de0, 0xf0926460) at netbsd:ufs_create+0x30
>   ufs_create(0xf4538c3c, 0xfffffff8, 0x0, 0x0, 0xf096ef2c, 0xf0970328) at netbsd:VOP_CREATE+0x28
>   VOP_CREATE(0xf0970328, 0xf4538dcc, 0xf4538de0, 0xf4538cb0, 0xf0002000, 0xf0785150) at netbsd:vn_open+0x24c
>   vn_open(0x0, 0x602, 0x1a4, 0xf069cb28, 0xf0851000, 0xf4538db8) at netbsd:do_open+0x90
>   do_open(0x0, 0x0, 0xf0785150, 0x602, 0x1a4, 0xf4538ec4) at netbsd:do_sys_openat+0x60
>   do_sys_openat(0xf0aa05a0, 0xffffff9c, 0xeda08080, 0x601, 0x1a4, 0xf4538ec4) at netbsd:sys_open+0x18
>   sys_open(0xf0aa05a0, 0xf4538f30, 0xf4538f28, 0xeda08080, 0x0, 0x169b04f) at netbsd:syscall+0x248
>   syscall(0xc05, 0xf4538fb0, 0xedc06b58, 0x5, 0x4e, 0xf0aa05a0) at netbsd:memfault_sun4m+0x3f4
>   cpu0: End traceback...
>
> More logs at:
>
>   http://releng.netbsd.org/b5reports/sparc/commits-2016.10.html#2016.10.30.19.33.49
>
> The strange thing is that this problem seems to have started soon
> after your report, not before it as I would expect if it were also the
> cause of your crash.  The filesystems involved are all newly created
> in each test run.
> --
> Andreas Gustafsson, gson%gson.org@localhost

Index: ffs_inode.c
===================================================================
RCS file: /cvsroot/src/sys/ufs/ffs/ffs_inode.c,v
retrieving revision 1.118
diff -u -r1.118 ffs_inode.c
--- ffs_inode.c	28 Oct 2016 20:38:12 -0000	1.118
+++ ffs_inode.c	2 Nov 2016 21:15:11 -0000
@@ -543,6 +543,7 @@
 	oip->i_size = length;
 	DIP_ASSIGN(oip, size, length);
 	DIP_ADD(oip, blocks, -blocksreleased);
+	KASSERT((DIP(oip, size) == 0) == (DIP(oip, blocks) == 0));
 	genfs_node_unlock(ovp);
 	oip->i_flag |= IN_CHANGE;
 	UFS_WAPBL_UPDATE(ovp, NULL, NULL, 0);