Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932683AbdHWVBr (ORCPT ); Wed, 23 Aug 2017 17:01:47 -0400 Received: from mail-it0-f45.google.com ([209.85.214.45]:37239 "EHLO mail-it0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751774AbdHWVBp (ORCPT ); Wed, 23 Aug 2017 17:01:45 -0400 From: Andreas Dilger Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_FC299555-5FCF-4639-ABAA-31FA9EDD376B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Kernels v4.9+ cause short reads of block devices Date: Wed, 23 Aug 2017 15:01:38 -0600 In-Reply-To: Cc: Doug Nazar , Al Viro , Linux Kernel Mailing List , Wei Fang , linux-fsdevel , Mark Fasheh , Joel Becker , Dave Kleikamp To: Linus Torvalds References: <1ae53e17-e455-4f17-0280-b0dae183a449@nazar.ca> X-Mailer: Apple Mail (2.3273) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3510 Lines: 104 --Apple-Mail=_FC299555-5FCF-4639-ABAA-31FA9EDD376B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 23, 2017, at 2:13 PM, Linus Torvalds = wrote: >=20 > On Wed, Aug 23, 2017 at 12:53 PM, Doug Nazar wrote: >>=20 >> It's compiling now, but I think it's already set to MAX_LFS_FILESIZE. >>=20 >> [ 169.095127] ppos=3D80180006000, s_maxbytes=3D7ffffffffff, = magic=3D0x62646576, >> type=3Dbdev >=20 > Oh, right you are - I'm much too used to 64-bit, where > MAX_LFS_FILESIZE is basically infinite, and was jusr assuming that it > was something like the UFS bug we had not that long ago that was due > to the 32-bit limit. >=20 > But yes, on 32-bit, we are limited by the 32-bit index into the page > cache, and we limit the index to 31 bits too, so we have (PAGE_SIZE << > 31) -1, which is that 7ffffffffff. >=20 > And that also explains why people haven't seen it. You do need >=20 > (a) 32-bit environment >=20 > (b) a disk larger than that 8TB in size >=20 > The *hard* limit for the page cache on a 32-bit environment should > actually be (PAGE_SIZE << 32)-PAGE_SIZE (that final PAGE_SIZE > subtraction is to make sure we don't generate that page cache with > index -1), so having a disk that is 16TB or larger is not going to > work, but your disk is right in that 8TB-16TB hole that used to work > and was broken by that check. >=20 > Anyway, that makes me feel better. I should have looked at your disk > size more, now I at least understand why nobody noticed before. >=20 > So just throw away my patch. That's wrong, and garbage. >=20 > The *right* patch is likely to just this instead: >=20 > -#define MAX_LFS_FILESIZE (((loff_t)PAGE_SIZE << = (BITS_PER_LONG-1))-1) > +#define MAX_LFS_FILESIZE (((loff_t)PAGE_SIZE << > BITS_PER_LONG)-PAGE_SIZE) >=20 > which should make MAX_LFS_FILESIZE be 0xffffffff000 and you disk size > should be ok. Doug, I noticed while checking for other implications of changing = MAX_LFS_FILESIZE that fs/jfs/super.c is also working around this limit. If you are going to submit a patch for this, it also makes sense to fix jfs_fill_super() = to use MAX_LFS_FILESIZE instead of JFS rolling its own, something like: /* logical blocks are represented by 40 bits in pxd_t, etc. * and page cache is indexed by long. */ sb->s_maxbytes =3D min((u64)sb->s_blocksize) << 40, MAX_LFS_FILESIZE); It also looks like ocfs2_max_file_offset() is trying to avoid = overflowing the old 31-bit limit, and isn't using MAX_LFS_FILESIZE directly, so it = will now be wrong. It looks like it could use "bitshift =3D 32; trim =3D = bytes;", but Joel or Mark should confirm. Finally, there is a check in fs/super.c::mount_fs() that is verifying s_maxbytes is not set too large, but this has been present since 2.6.32 and should probably be removed at this point, or changed to a BUG_ON() (see commit 42cb56ae2ab for details). Cheers, Andreas --Apple-Mail=_FC299555-5FCF-4639-ABAA-31FA9EDD376B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFZne0zpIg59Q01vtYRAruTAJwJFDSSxPxyYIrYENgKwI0yOGlDgACgmfWw w/uV8zUlYBbXgGrdfpx1k84= =EGYN -----END PGP SIGNATURE----- --Apple-Mail=_FC299555-5FCF-4639-ABAA-31FA9EDD376B--