From nobody Wed Jun 01 02:58:40 2022 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B6EF21B3DF99; Wed, 1 Jun 2022 02:58:40 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LCYkS4fXBz4vCl; Wed, 1 Jun 2022 02:58:40 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654052320; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=0iKBfucmkQV/6aYsbryjzC5dg2InbBqLSFAraHXlsOQ=; b=kGTJBrHHu8dlk53of2lDYKiXH3HvZQzP6/HZHBDOLvsuTaGlZtX4goGR6o9IUfNdmCVsDw NThGbm2/NnIPKfSlpdRZwLBfPqXEx3IoAZIfGkJogfOja22+kB3ZVgCJNpQA9jILqruztO aUWiWDjAJpPWOo6RMDqIxKbZenYE2gf9944q1KHJpPlGHvvtuTP9mKYk64h2n53q/V5TGT cw1EAa4NZPTxAI5LwqwHfcozcwx/VGmwfS1S/HOZh3EeoM95B5BUh+oRyQU+JAKYiyUAaE JHKAGaEGzQQJ2sLJmeKMglkLyqYevqkT/9DY1+vEJV+Q060KmFkenVgcJcb7Rw== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 74DBF18503; Wed, 1 Jun 2022 02:58:40 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 2512weOn005633; Wed, 1 Jun 2022 02:58:40 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 2512weKm005632; Wed, 1 Jun 2022 02:58:40 GMT (envelope-from git) Date: Wed, 1 Jun 2022 02:58:40 GMT Message-Id: <202206010258.2512weKm005632@gitrepo.freebsd.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org From: Kirk McKusick Subject: git: bc218d89200f - main - Two bug fixes to UFS/FFS superblock integrity checks when reading a superblock. List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: mckusick X-Git-Repository: src X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: bc218d89200faa021def77732f3d9fde4f4dee13 Auto-Submitted: auto-generated ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654052320; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=0iKBfucmkQV/6aYsbryjzC5dg2InbBqLSFAraHXlsOQ=; b=lSBJ0k0BqO5A0DqzFBdEOof8aa0///5l2AhJr17Qe6dwGU38CSh+eYMpcRE4XDtrV5ghDX 6ktiPzRwIlxoZ1pxz+hs1r1tVt8tm7RloOdjP86QwosauafABvvMediNymoRpk1N6wxrrH Mt68Itsks/DsqeOapRqMwWLc/pI9+0AjC43Ar5+Re+iBfVU18JXOz1U7PQ2ghq5EZHDwlI toDWjg2bFdX1wLyPdOLEGdzxEgOnlmso7YrWGLsxZKiR0Uf3NTN0TUAYLoNSDFmJ5tcPDh oA2zyQkD/p3wTy8Ps8Lr77qlJrkt36p6n858SiNtNvf5Avhay71iTwomp0Ht+Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654052320; a=rsa-sha256; cv=none; b=d4rvBXYYgGTDd9XvxR7WdHQw+v9Qss9RkWi1Mwo4PFrmiAJsQCK0IIMa361VIXLOLUpJaj PBzujiiaTVwWA47xvKK69dP0fZEOxlzEmweFAwzFoY/edBDOdEhg4DiU0dz508FA3ZPmjB A7g9sJ/C/jpEdwZscbEmDSL0DrE6NMmaLIY4ZbcONotcS+eJ1sNRXJ0hlzw8YBcdj38CLl rRNp9T4CgFtGw+gdMqHmM6GCmJ/vNfP1YJ3OPbq+j+gRk2LRoNoKyag1qRRkSJumT0k766 haoeKqGqqZUDeBVb7bkuilePeUETkw5R6Tpp/0X/MTFdsO6BEIfX07SVamqTtA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by mckusick: URL: https://cgit.FreeBSD.org/src/commit/?id=bc218d89200faa021def77732f3d9fde4f4dee13 commit bc218d89200faa021def77732f3d9fde4f4dee13 Author: Kirk McKusick AuthorDate: 2022-06-01 02:55:54 +0000 Commit: Kirk McKusick CommitDate: 2022-06-01 02:58:37 +0000 Two bug fixes to UFS/FFS superblock integrity checks when reading a superblock. Two bugs have been reported with the UFS/FFS superblock integrity checks that were added in commit 076002f24d35. The code checked that fs_sblockactualloc was properly set to the location of the superblock. The fs_sblockactualloc field was an addition to the superblock in commit dffce2150eea on Jan 26 2018 and used a field that was zero in filesystems created before it was added. The integrity check had to be expanded to accept the fs_sblockactualloc field being zero so as not to reject filesystems created before Jan 26 2018. The integrity check set an upper bound on the value of fs_maxcontig based on the maximum transfer size supported by the kernel. It required that fs->fs_maxcontig <= maxphys / fs->fs_bsize. The kernel variable maxphys defines the maximum transfer size permitted by the controllers and/or buffering. The fs_maxcontig parameter controls the maximum number of blocks that the filesystem will read or write in a single transfer. It is calculated when the filesystem is created as maxphys / fs_bsize. The bug appeared in the loader because it uses a maxphys of 128K even when running on a system that supports larger values. If the filesystem was built on a system that supports a larger maxphys (1M is typical) it will have configured fs_maxcontig for that larger system so would fail the test when run with the smaller maxphys used by the loader. So we bound the upper allowable limit for fs_maxconfig to be able to at least work with a 1M maxphys on the smallest block size filesystem: 1M / 4096 == 256. We then use the limit for fs_maxcontig as fs_maxcontig <= MAX(256, maxphys / fs_bsize). There is no harm in allowing the mounting of filesystems that make larger than maxphys I/O requests because those (mostly 32-bit machines) can (very slowly) handle I/O requests that exceed maxphys. Thanks to everyone who helped sort out the problems and the fixes. Reported by: Cy Schubert, David Wolfskill Diagnosis by: Mark Johnston, John Baldwin Reviewed by: Warner Losh Tested by: Cy Schubert, David Wolfskill MFC after: 1 month (with 076002f24d35) Differential Revision: https://reviews.freebsd.org/D35219 --- sys/ufs/ffs/ffs_subr.c | 29 ++++++++++++++++++++++------- 1 file changed, 22 insertions(+), 7 deletions(-) diff --git a/sys/ufs/ffs/ffs_subr.c b/sys/ufs/ffs/ffs_subr.c index 28c2fee1cb37..f25a6cba12f4 100644 --- a/sys/ufs/ffs/ffs_subr.c +++ b/sys/ufs/ffs/ffs_subr.c @@ -319,7 +319,8 @@ validate_sblock(struct fs *fs, int isaltsblk) sectorsize = dbtob(1); if (fs->fs_magic == FS_UFS2_MAGIC) { if ((!isaltsblk && (fs->fs_sblockloc != SBLOCK_UFS2 || - fs->fs_sblockactualloc != SBLOCK_UFS2)) || + !(fs->fs_sblockactualloc == 0 || + fs->fs_sblockactualloc == SBLOCK_UFS2))) || fs->fs_maxsymlinklen != ((UFS_NDADDR + UFS_NIADDR) * sizeof(ufs2_daddr_t)) || fs->fs_nindir != fs->fs_bsize / sizeof(ufs2_daddr_t) || @@ -327,7 +328,8 @@ validate_sblock(struct fs *fs, int isaltsblk) return (ENOENT); } else if (fs->fs_magic == FS_UFS1_MAGIC) { if ((!isaltsblk && (fs->fs_sblockloc > SBLOCK_UFS1 || - fs->fs_sblockactualloc != SBLOCK_UFS1)) || + !(fs->fs_sblockactualloc == SBLOCK_UFS1 || + fs->fs_sblockactualloc == 0))) || fs->fs_nindir != fs->fs_bsize / sizeof(ufs1_daddr_t) || fs->fs_inopb != fs->fs_bsize / sizeof(struct ufs1_dinode) || fs->fs_maxsymlinklen != ((UFS_NDADDR + UFS_NIADDR) * @@ -423,13 +425,26 @@ validate_sblock(struct fs *fs, int isaltsblk) fs->fs_size > fs->fs_ncg * fs->fs_fpg) return (ENOENT); /* - * Maxcontig sets the default for the maximum number of blocks - * that may be allocated sequentially. With file system clustering - * it is possible to allocate contiguous blocks up to the maximum - * transfer size permitted by the controller or buffering. + * With file system clustering it is possible to allocate + * many contiguous blocks. The kernel variable maxphys defines + * the maximum transfer size permitted by the controller and/or + * buffering. The fs_maxcontig parameter controls the maximum + * number of blocks that the filesystem will read or write + * in a single transfer. It is calculated when the filesystem + * is created as maxphys / fs_bsize. The loader uses a maxphys + * of 128K even when running on a system that supports larger + * values. If the filesystem was built on a system that supports + * a larger maxphys (1M is typical) it will have configured + * fs_maxcontig for that larger system. So we bound the upper + * allowable limit for fs_maxconfig to be able to at least + * work with a 1M maxphys on the smallest block size filesystem: + * 1M / 4096 == 256. There is no harm in allowing the mounting of + * filesystems that make larger than maxphys I/O requests because + * those (mostly 32-bit machines) can (very slowly) handle I/O + * requests that exceed maxphys. */ if (fs->fs_maxcontig < 1 || - fs->fs_maxcontig > MAX(1, maxphys / fs->fs_bsize)) + fs->fs_maxcontig > MAX(256, maxphys / fs->fs_bsize)) return (ENOENT); if (fs->fs_maxcontig < 0 || (fs->fs_maxcontig == 0 && fs->fs_contigsumsize != 0) ||