From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 23 18:37:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD13116A4CE for ; Fri, 23 Apr 2004 18:37:06 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC85743D54 for ; Fri, 23 Apr 2004 18:37:06 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i3O1b47Z010071; Fri, 23 Apr 2004 18:37:04 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i3O1b4W0010070; Fri, 23 Apr 2004 18:37:04 -0700 (PDT) (envelope-from dillon) Date: Fri, 23 Apr 2004 18:37:04 -0700 (PDT) From: Matthew Dillon Message-Id: <200404240137.i3O1b4W0010070@apollo.backplane.com> To: Stephan Uphoff References: <200404232345.TAA10405@stups.com> cc: hackers@freebsd.org cc: Julian Elischer cc: Stephan Uphoff Subject: Re: Re99: how to flush out cache.? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 01:37:06 -0000 :When I get the time (probably not next week) I will write a patch :to release the cached buffers that would prevent page removal. I would appreciate a CC if/when you have something along these lines. It won't be easy. The VM system has no reliable way to determine the buffer cache block size for a VM object or VNODE, nor any idea how to deal with the buffer state which can vary in subtle ways between VFS's (e.g. NFS vs UFS). So a new VOP call would probably have to be created to clean out the buffers associated with a memory range. We might want to create such a call anyway in order to support ranged fsync()'s. :The bug affects only in memory modified file data. : :In memory modifications to the file can be deleted :and the file data reverts to a state before the :file modification. (Not unlike a crash/power failure ) : :The worst security scenario I can think of is the possibility :to revert a file to uninitialized disk data blocks or to :prevent the update of a file. : : Stephan I won't say that it's imposible, but it would sure be hard to accomplish since access to uninitialized disk data blocks is going to be governed by the buffer cache, and the buffer is cleared unconditionally when balloc'd inside ffs_write() (and the blocks will not be assigned if one tries to do a read() if a file hole). The only other code that calls VOP_BALLOC() for a file block is ftruncate(), and it also does an unconditional write. -Matt Matthew Dillon