Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Mar 2019 19:08:41 +0000 (UTC)
From:      Kirk McKusick <mckusick@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   svn commit: r345077 - head/sys/kern
Message-ID:  <201903121908.x2CJ8fCI028561@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: mckusick
Date: Tue Mar 12 19:08:41 2019
New Revision: 345077
URL: https://svnweb.freebsd.org/changeset/base/345077

Log:
  This is an additional fix for bug report 230962. When using
  extended attributes, the kernel can panic with either "ffs_truncate3"
  or with "softdep_deallocate_dependencies: dangling deps".
  
  The problem arises because the flushbuflist() function which is
  called to clear out buffers is passed either the V_NORMAL flag to
  indicate that it should flush buffer associated with the contents
  of the file or the V_ALT flag to indicate that it should flush the
  buffers associated with the extended attribute data. The buffers
  containing the extended attribute data are identified by having
  their BX_ALTDATA flag set in the buffer's b_xflags field. The
  BX_ALTDATA flag is set on the buffer when the extended attribute
  block is first allocated or when its contents are read in from the
  disk.
  
  On a busy system, a buffer may be reused for another purpose, but
  the contents of the block that it contained continues to be held
  in the main page cache. Each physical page is identified as holding
  the contents of a logical block within a specified file (identified
  by a vnode). When a request is made to read a file, the kernel first
  looks for the block in the existing buffers.  If it is not found
  there, it checks the page cache to see if it is still there. If
  it is found in the page cache, then it is remapped into a new
  buffer thus avoiding the need to read it in from the disk.
  
  The bug is that when a buffer request made for an extended attribute
  is fulfilled by reconstituting a buffer from the page cache rather
  than reading it in from disk, the BX_ALTDATA flag was not being
  set. Thus the flushbuflist() function would never clear it out and
  the "ffs_truncate3" panic would occur because the vnode being cleared
  still had buffers on its clean-buffer list. If the extended attribute
  was being updated, it is first read, then updated, and finally
  written. If the read is fulfilled by reconstituting the buffer
  from the page cache the BX_ALTDATA flag was not set and thus the
  dirty buffer would never be flushed by flushbuflist(). Eventually
  the buffer would be recycled. Since it was never written it would
  have an unfinished dependency which would trigger the
  "softdep_deallocate_dependencies: dangling deps" panic.
  
  The fix is to ensure that the BX_ALTDATA flag is set when a buffer
  has been reconstituted from the page cache.
  
  PR:           230962
  Reported by:  2t8mr7kx9f@protonmail.com
  Reviewed by:  kib
  Tested by:    Peter Holm
  MFC after:    1 week
  Sponsored by: Netflix

Modified:
  head/sys/kern/vfs_bio.c

Modified: head/sys/kern/vfs_bio.c
==============================================================================
--- head/sys/kern/vfs_bio.c	Tue Mar 12 19:03:47 2019	(r345076)
+++ head/sys/kern/vfs_bio.c	Tue Mar 12 19:08:41 2019	(r345077)
@@ -4842,6 +4842,8 @@ b_io_dismiss(struct buf *bp, int ioflag, bool release)
 
 	if ((ioflag & IO_DIRECT) != 0)
 		bp->b_flags |= B_DIRECT;
+	if ((ioflag & IO_EXT) != 0)
+		bp->b_xflags |= BX_ALTDATA;
 	if ((ioflag & (IO_VMIO | IO_DIRECT)) != 0 && LIST_EMPTY(&bp->b_dep)) {
 		bp->b_flags |= B_RELBUF;
 		if ((ioflag & IO_NOREUSE) != 0)



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