panic ffs_truncate3 (maybe fuse being evil)

[Rick Macklem]

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.

If you have another patch to try, email it and I'll try and reproduce the
failure without/with the patch.

rick