MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Date: Mon, 9 Aug 2010 15:50:13 +0000
From: Antti Kantee <pooka@netbsd.org>
Subject: CVS commit: src/sys/ufs/ffs
To: source-changes@NetBSD.org
Message-Id: <20100809155013.D7381175DD@cvs.netbsd.org>
Sender: source-changes-owner@NetBSD.org
Precedence: list
Reply-To: source-changes-d@NetBSD.org
Mail-Reply-To: Antti Kantee <pooka@netbsd.org>
Mail-Followup-To: source-changes-d@NetBSD.org

Module Name:	src
Committed By:	pooka
Date:		Mon Aug  9 15:50:13 UTC 2010

Modified Files:
	src/sys/ufs/ffs: ffs_vfsops.c

Log Message:
Return error if we try to mount a file system with block size > MAXBSIZE.

Note: there is a billion ways to make the kernel panic by trying
to mount a garbage file system and I don't imagine we'll ever get
close to fixing even half of them.  However, for this one failing
gracefully is a bonus since Xen DomU only does 32k MAXBSIZE and
the 64k MAXBSIZE file systems are out there (PR port-xen/43727).

Tested by compiling sys/rump with CPPFLAGS+=-DMAXPHYS=32768 (all
tests in tests/fs still pass).  I don't know how we're going to
translate this into an easy regression test, though.  Maybe with
a hacked newfs?


To generate a diff of this commit:
cvs rdiff -u -r1.260 -r1.261 src/sys/ufs/ffs/ffs_vfsops.c

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