NetBSD Problem Report #50246

From dholland@netbsd.org  Mon Sep 14 17:36:48 2015
Return-Path: <dholland@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 4637BA654F
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 14 Sep 2015 17:36:48 +0000 (UTC)
Message-Id: <20150914173648.0D7A414A22F@mail.netbsd.org>
Date: Mon, 14 Sep 2015 17:36:48 +0000 (UTC)
From: dholland@netbsd.org
Reply-To: dholland@netbsd.org
To: gnats-bugs@gnats.NetBSD.org
Subject: lfs volumes created with wrong ifpb value
X-Send-Pr-Version: 3.95

>Number:         50246
>Category:       kern
>Synopsis:       lfs volumes created with wrong ifpb value
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    dholland
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Sep 14 17:40:00 +0000 2015
>Closed-Date:    
>Last-Modified:  Mon Sep 21 02:13:51 +0000 2015
>Originator:     David A. Holland
>Release:        NetBSD 7.99.21 (20150914)
>Organization:
>Environment:
System: NetBSD macaran 7.99.20 NetBSD 7.99.20 (MACARAN) #30: Mon Jul 27 20:25:15 EDT 2015  dholland@macaran:/usr/src/sys/arch/amd64/compile/MACARAN amd64
Architecture: x86_64
Machine: amd64
>Description:

If you newfs a 32-bit lfs volume with a non-default block size, it
recalculates a number of superblock fields that depend on the block
size. The recalculation of 'ifpb' (ifile entries per block) uses
sizeof(IFILE); unfortunately, since the introduction of separate
IFILE32/IFILE64 structures on 20150812, IFILE is a union and its size
is the size of the (larger) IFILE64 structure. Therefore, the ifpb
value recorded in the superblock is smaller than it should be.

This *should* be harmless (at a cost of some wasted space) as all code
should be using the superblock ifpb value and not recomputing it on
the fly; but this is not guaranteed and there's a certain risk of
stepping on otherwise-invisible bugs.

>How-To-Repeat:

Code inspection.

>Fix:

The fix is trivial (and pending once I chase down some test failures
that probably aren't related); the question is what the consequences
are. Once the fix is in place, if you have such a volume and can
easily re-newfs it, it's probably a good idea to do so as a safety
precaution. 

(The space consumption isn't that big a deal; while the ifile entry in
lfs64 is substantially larger, 32 bytes vs. 20, the space wasted works
out to something like 0.1% of the volume size.)

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->dholland
Responsible-Changed-By: dholland@NetBSD.org
Responsible-Changed-When: Mon, 14 Sep 2015 17:52:30 +0000
Responsible-Changed-Why:
mine


From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/50246 CVS commit: src
Date: Mon, 21 Sep 2015 01:24:59 +0000

 Module Name:	src
 Committed By:	dholland
 Date:		Mon Sep 21 01:24:58 UTC 2015

 Modified Files:
 	src/sbin/dump_lfs: lfs_inode.c
 	src/sbin/newfs_lfs: make_lfs.c
 	src/sys/ufs/lfs: lfs_accessors.h

 Log Message:
 Fix some assorted 32-bit assumptions not yet otherwise handled.

 Also apply patch to fix the overt problem in PR 50246: newfs was
 calculating ifpb wrong for volumes with non-default block sizes.


 To generate a diff of this commit:
 cvs rdiff -u -r1.26 -r1.27 src/sbin/dump_lfs/lfs_inode.c
 cvs rdiff -u -r1.56 -r1.57 src/sbin/newfs_lfs/make_lfs.c
 cvs rdiff -u -r1.32 -r1.33 src/sys/ufs/lfs/lfs_accessors.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->analyzed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 21 Sep 2015 02:13:51 +0000
State-Changed-Why:
mistake is fixed, still contemplating steps to take regarding extant
volumes that may have been created this way.


>Unformatted:

Home	PR Database Search