Re: ffs_truncate3 panics

On Thu, Aug 09, 2018 at 01:39:20AM +0000, Rick Macklem wrote:
> Konstantin Belousov wrote:
> [stuff snipped]
> >> >Can you print the only buffer on the clean queue when the panic occur ?
> >> ffst3 vtyp=1 bodirty=0 boclean=1
> >> buf at 0x428a110
> >> b_flags = 0x20001020<vmio,reuse,cache>, b_xflags=0x2<clean>, b_vflags=0x0
> >> b_error = 0, b_bufsize = 4096, b_bcount = 4096, b_resid = 0
> >> b_bufobj = (0xfd8ba94), b_data = 0x5170000, b_blkno = -1, b_lblkno = -1, b_dep = 0
> >> b_kvabase = 0x5170000, b_kvasize = 32768
> >So the buffer was indeed for extended attrs, and never written to the disk.
> >I am quite interested what was the inode content prior to the truncation,
> >esp. the di_extsize.
> Just in case it wasn't clear, this buffer is on the clean list and not the dirty one.
> (Does this mean it somehow got onto the "clean list" without being written to disk?)
> 
> >Could you try to formulate a way to reproduce the panic so that Peter
> >can recreate it, please ?
> I doubt it. It would require him doing a pNFS setup with multiple systems.
> (At least that is the only way I reproduce it and I sometimes go a week of testing
>  before I see them.)
> It would be great to have more testers for the pNFS server stuff, but I doubt it
> would fit into Peter's setup?
> 
> I can add printf()s anywhere you suggest, but I'm not sure how you would catch
> this case sooner? (For example, I could print out di_extsize at the beginning of
> ffs_truncate(), if that would help?)
May be, add a loop at the beginning of ffs_truncate(), over all buffers
on both clean and dirty queues, calculating number of buffers with
b_lblkno < 0 and >= -UFS_NXADDR. Print some diagnostic if such buffer is
detected but di_extsize is zero.

BTW, does NFS server use extended attributes ?  What for ?  Can you, please,
point out the code which does this ?