panic ffs_truncate3 (maybe fuse being evil)

[Rick Macklem]

Kostik wrote:
> On Mon, Feb 01, 2016 at 08:07:19PM -0500, Rick Macklem wrote:
> > Kostik wrote:
> > > On Mon, Jan 18, 2016 at 11:25:16PM -0500, Rick Macklem wrote:
> > > > Kostik wrote:
> > > > > On Sat, Jan 16, 2016 at 06:20:31PM -0500, Rick Macklem wrote:
> > > > > > Kostik wrote:
> > > > > > > Was IO_EXT flag passed to the ffs_truncate() invocation where the
> > > > > > > assert ffs_truncate3 fired ?
> > > > > > > 
> > > > > > Yes. The only call to UFS_TRUNCATE() in ufs_inactive() specified
> > > > > > both
> > > > > > IO_EXT | IO_NORMAL.
> > > > > 
> > > > > Please try this.
> > > > > 
> > > > Still happens. I put the old panic test in, but with a printf() instead
> > > > of panic() and the printf() happens with this patch.
> > > > Btw, whenever I've looked, the entry is on the clean list.
> > > > No other panics happen and the file system fsck's fine after the test
> > > > run.
> > > 
> > > I thought that you posted a stand-alone program which triggered the issue
> > > on non-SU mounts, but I cannot find it.  Does such program exist, or this
> > > is just me misremembering ?
> > > 
> > Nope. I do a test run using GlusterFS (a FreeBSD kernel build with the
> > sources
> > on GlusterFS) where the bricks are on UFS file systems with SU disabled.
> > 
> > To be honest, I've been using ZFS for tests lately, so I'm not even sure I
> > remember exactly what the test setup was, but I think the above is it.
> > (It takes 2-3hrs for an occurrence to happen.)
> > 
> > I did plan on taking a look at vinvalbuf(..V_ALT..), since that is what I
> > think should be getting rid of the extended attribute block, but haven't
> > done so.
> I doubt that this is vinvalbuf(), more likely it is stray buffer forgotten
> by some cleanup code.  Note that ffs_truncate() condition to call
> vinvalbuf(V_ALT) is that IO_EXT flag is passed and dinode di_extsize field
> value is > 0.
> 
I didn't notice the di_extsize > 0 and I see the panic is with di_extsize == 0.
(At a glance I didn't see anything suspicious in vinvalbuf() anyhow.)

> > 
> > If you have another patch to try, email it and I'll try and reproduce the
> > failure without/with the patch.
> I asked about the test program to be able to trace the issue.
Unfortunately I doubt a simple program will reproduce it.
GlusterFS loves to read extended attributes, so I'd guess it has read at least
100,000 of them by the time it hits the panic in a test run.
(It loves doing system calls, so I don't run ktrace for long, but I recall 10+
 get_link_extattr (or whatever the exact name is, the "get extended attribute without
 following symlinks" one) in a 1second ktrace.)

rick

> I do think that the IO_UNIT patch fixes some situations where the buffer
> can be left on the vnode queue.  I did not found any other places so far.
>