From owner-freebsd-current  Tue May  1 12:15:38 2001
Delivered-To: freebsd-current@freebsd.org
Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147])
	by hub.freebsd.org (Postfix) with ESMTP id D243A37B423
	for <current@freebsd.org>; Tue,  1 May 2001 12:15:34 -0700 (PDT)
	(envelope-from peter@wemm.org)
Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3])
	by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f41JFYM91100
	for <current@freebsd.org>; Tue, 1 May 2001 12:15:34 -0700 (PDT)
	(envelope-from peter@wemm.org)
Received: from wemm.org (localhost [127.0.0.1])
	by overcee.netplex.com.au (Postfix) with ESMTP id 96E1A380C
	for <current@freebsd.org>; Tue,  1 May 2001 12:15:34 -0700 (PDT)
	(envelope-from peter@wemm.org)
X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4
To: current@freebsd.org
Subject: HEADS UP! bad bug in -current.
Date: Tue, 01 May 2001 12:15:34 -0700
From: Peter Wemm <peter@wemm.org>
Message-Id: <20010501191534.96E1A380C@overcee.netplex.com.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Any -current kernel built over the weekend is a likely victim of this bug.
In a nutshell, it will eat your root filesystem at the very least, leaving
you with maybe one or two files in /lost+found.  spec_vnops.c rev 1.156
is should be avoided at all costs.

BEWARE: there are some snapshots on current.freebsd.org with this bug. They
will self destruct after install.

------- Forwarded Messages

phk         2001/04/29 04:48:42 PDT

  Modified files:
...[other files in commit trimmed]
    sys/miscfs/specfs    spec_vnops.c 
  Log:
  Add a vop_stdbmap(), and make it part of the default vop vector.
  
  Make 7 filesystems which don't really know about VOP_BMAP rely
  on the default vector, rather than more or less complete local
  vop_nopbmap() implementations.

  Revision  Changes    Path
  1.156     +1 -2      src/sys/miscfs/specfs/spec_vnops.c

------- Message 2

bde         2001/04/30 07:35:37 PDT

  Modified files:
    sys/miscfs/specfs    spec_vnops.c 
  Log:
  Backed out previous commit.  It cause massive filesystem corruption,
  not to mention a compile-time warning about the critical function
  becoming unused, by replacing spec_bmap() with vop_stdbmap().
  
  ntfs seems to have the same bug.
  
  The factor for converting specfs block numbers to physical block
  numbers is 1, but vop_stdbmap() uses the bogus factor
  btodb(ap->a_vp->v_mount->mnt_stat.f_iosize), which is 16 for ffs with
  the default block size of 8K.  This factor is bogus even for vop_stdbmap()
  -- the correct factor is related to the filesystem blocksize which is not
  necessarily the same to the optimal i/o size.  vop_stdbmap() was apparently
  cloned from nfs where these sizes happen to be the same.
  
  There may also be a problem with a_vp->v_mount being null.  spec_bmap()
  still checks for this, but I think the checks in specfs are dead code
  which used to support block devices.

  Revision  Changes    Path
  1.157     +2 -1      src/sys/miscfs/specfs/spec_vnops.c

------- End of Forwarded Messages



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message