From patchwork Mon Jun 5 00:02:41 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Al Viro X-Patchwork-Id: 9765297 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 590466034B for ; Mon, 5 Jun 2017 00:02:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 48C7327C2D for ; Mon, 5 Jun 2017 00:02:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3C79427CEA; Mon, 5 Jun 2017 00:02:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C414727C2D for ; Mon, 5 Jun 2017 00:02:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751202AbdFEACp (ORCPT ); Sun, 4 Jun 2017 20:02:45 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:40214 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751181AbdFEACo (ORCPT ); Sun, 4 Jun 2017 20:02:44 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1dHfTl-0000EO-EQ; Mon, 05 Jun 2017 00:02:41 +0000 Date: Mon, 5 Jun 2017 01:02:41 +0100 From: Al Viro To: Theodore Ts'o Cc: Linus Torvalds , Richard Narron , Will B , linux-fsdevel Subject: Re: UFS s_maxbytes bogosity Message-ID: <20170605000241.GO6365@ZenIV.linux.org.uk> References: <20170604213736.GM6365@ZenIV.linux.org.uk> <20170604215838.GA24416@ZenIV.linux.org.uk> <20170604223249.xettrnuec5vqrlyq@thunk.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170604223249.xettrnuec5vqrlyq@thunk.org> User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Sun, Jun 04, 2017 at 06:32:49PM -0400, Theodore Ts'o wrote: > On Sun, Jun 04, 2017 at 10:58:38PM +0100, Al Viro wrote: > > > > ought to calculate the right thing for modern UFS variants; I would > > leave the anything other than UFS_MOUNT_UFSTYPE_44BSD and > > UFS_MOUNT_UFSTYPE_UFS2 alone. > > If anyone wants to spend time worrying about ancient UFS > incompatilities, or wants to find someone who might care, there's the > The Unix Heritage Society mailing list[1]. (Don't bother trying to > post the list without subscribing first, the list is run even more > strictly than DaveM, and postings from people who aren't subscribers > get unceremoniously dropped on the floor.) > > [1] http://minnie.tuhs.org/mailman/listinfo/tuhs > > Among other things, recents discussion on this list discuss security > vulnerabilities (stack buffer overruns, et.al) on V6 and V7 Unix, and > there are people on that list who will bring up historical versions of > Unix on emulators, et. al. > > More seriously, many of UFS variants don't have any way of > distinguishing between what version they are, or are safe to mount on > which version of Unix. There's a reason why ext2/3/4 has rather > feature compatibility masks; UFS demonstrated the joys of what happens > when you don't bother with that kind of compatibility markers in file > systems. So focusing just on what FreeBSD and other modern BSD > implementation use is a completely fair thing to do. The enthusiasts > on TUHS are perfectly capable of sending patches if they care about V6 > Unix <-> Linux compatibility. :-) FFS and derivatives postdate v7, let alone v6, as you bloody well know ;-) Anyway, there are two issues - access on Linux not getting unhappy and *BSD kernels being OK with created huge files. After rereading that code, for UFS2 the function I'd posted would do the right thing; for UFS1 there's an additional complication - on-disk ui_blocks (in units of 512 bytes) being only 32bit. So for UFS1 we need to make sure we won't overflow that thing, making for hard limit a bit below 2^41 bytes, in addition to the limit imposed by the tree structure. How about this: diff --git a/fs/ufs/super.c b/fs/ufs/super.c index 131b2b77c818..eefa48499a6e 100644 --- a/fs/ufs/super.c +++ b/fs/ufs/super.c @@ -746,6 +746,23 @@ static void ufs_put_super(struct super_block *sb) return; } +static u64 ufs_max_bytes(struct super_block *sb) +{ + struct ufs_sb_private_info *uspi = UFS_SB(sb)->s_uspi; + int bits = uspi->s_apbshift; + u64 res; + + if (bits > 21) + res = ~0ULL; + else + res = UFS_NDADDR + (1LL << bits) + (1LL << (2*bits)) + + (1LL << (3*bits)); + + if (res >= (MAX_LFS_FILESIZE >> uspi->s_bshift)) + return MAX_LFS_FILESIZE; + return res << uspi->s_bshift; +} + static int ufs_fill_super(struct super_block *sb, void *data, int silent) { struct ufs_sb_info * sbi; @@ -823,6 +840,7 @@ static int ufs_fill_super(struct super_block *sb, void *data, int silent) uspi->s_fshift = 9; uspi->s_sbsize = super_block_size = 1536; uspi->s_sbbase = 0; + sb->s_maxbytes = min(ufs_max_bytes(sb),1ULL<<40); flags |= UFS_DE_44BSD | UFS_UID_44BSD | UFS_ST_44BSD | UFS_CG_44BSD; break; case UFS_MOUNT_UFSTYPE_UFS2: @@ -833,6 +851,7 @@ static int ufs_fill_super(struct super_block *sb, void *data, int silent) uspi->s_fshift = 9; uspi->s_sbsize = super_block_size = 1536; uspi->s_sbbase = 0; + sb->s_maxbytes = ufs_max_bytes(sb); flags |= UFS_TYPE_UFS2 | UFS_DE_44BSD | UFS_UID_44BSD | UFS_ST_44BSD | UFS_CG_44BSD; break;