Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Jan 2016 21:11:16 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Rick Macklem <rmacklem@uoguelph.ca>
Cc:        FreeBSD Filesystems <freebsd-fs@freebsd.org>, Kirk McKusick <mckusick@mckusick.com>
Subject:   Re: panic ffs_truncate3 (maybe fuse being evil)
Message-ID:  <20160116191116.GI3942@kib.kiev.ua>
In-Reply-To: <1817287612.162823118.1452909605928.JavaMail.zimbra@uoguelph.ca>
References:  <1696608910.154845456.1452438117036.JavaMail.zimbra@uoguelph.ca> <20160110154518.GU3625@kib.kiev.ua> <1773157955.158922767.1452698181137.JavaMail.zimbra@uoguelph.ca> <1351730674.159022044.1452699617235.JavaMail.zimbra@uoguelph.ca> <20160114092934.GL72455@kib.kiev.ua> <964333498.161527381.1452827658163.JavaMail.zimbra@uoguelph.ca> <20160115095749.GC3942@kib.kiev.ua> <1817287612.162823118.1452909605928.JavaMail.zimbra@uoguelph.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 15, 2016 at 09:00:05PM -0500, Rick Macklem wrote:
> --- ufs/ffs/ffs_inode.c.sav	2016-01-10 20:11:46.406682000 -0500
> +++ ufs/ffs/ffs_inode.c	2016-01-15 17:22:58.465991000 -0500
> @@ -544,7 +544,12 @@ done:
>  	BO_LOCK(bo);
>  	if (length == 0 &&
>  	    (fs->fs_magic != FS_UFS2_MAGIC || ip->i_din2->di_extsize == 0) &&
> -	    (bo->bo_dirty.bv_cnt > 0 || bo->bo_clean.bv_cnt > 0))
> +	    ((bo->bo_dirty.bv_cnt > 0 && (TAILQ_EMPTY(&bo->bo_dirty.bv_hd) ||
> +	     TAILQ_FIRST(&bo->bo_dirty.bv_hd)->b_lblkno >= 0 ||
> +	     TAILQ_FIRST(&bo->bo_dirty.bv_hd)->b_lblkno < -2)) ||
> +	     (bo->bo_clean.bv_cnt > 0 && (TAILQ_EMPTY(&bo->bo_clean.bv_hd) ||
> +	     TAILQ_FIRST(&bo->bo_clean.bv_hd)->b_lblkno >= 0 ||
> +	     TAILQ_FIRST(&bo->bo_clean.bv_hd)->b_lblkno < -2))))
>  		panic("ffs_truncate3");
>  	BO_UNLOCK(bo);
>  #endif /* INVARIANTS */

So I tried to rewrite the assert to be more readable, and noted a thing
which I should have noted much earlier.

The ip->i_din2->di_extsize == 0 test ensures that both extattr blocks
are deallocated.  In other words, even with the new information about
lba of the leaked buffers, the assert is still correct, it catched
stray buffer which should not be there.

Was IO_EXT flag passed to the ffs_truncate() invocation where the
assert ffs_truncate3 fired ?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160116191116.GI3942>