Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932951AbdHWThU (ORCPT ); Wed, 23 Aug 2017 15:37:20 -0400 Received: from mail-oi0-f41.google.com ([209.85.218.41]:34298 "EHLO mail-oi0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932705AbdHWThO (ORCPT ); Wed, 23 Aug 2017 15:37:14 -0400 MIME-Version: 1.0 In-Reply-To: <1ae53e17-e455-4f17-0280-b0dae183a449@nazar.ca> References: <1ae53e17-e455-4f17-0280-b0dae183a449@nazar.ca> From: Linus Torvalds Date: Wed, 23 Aug 2017 12:37:13 -0700 X-Google-Sender-Auth: vI5dK3_m_53vlEzHhu9Ewq1xJkw Message-ID: Subject: Re: Kernels v4.9+ cause short reads of block devices To: Doug Nazar , Al Viro Cc: Linux Kernel Mailing List , Wei Fang , linux-fsdevel Content-Type: multipart/mixed; boundary="001a113d0a8ab4f6f0055770d661" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2204 Lines: 53 --001a113d0a8ab4f6f0055770d661 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 23, 2017 at 12:15 PM, Doug Nazar wrote: > The following commits cause short reads of block devices, however writes are > still allowed. > > c2a9737f45e2 ("vfs,mm: fix a dead loop in truncate_inode_pages_range()") > d05c5f7ba164 ("vfs,mm: fix return value of read() at s_maxbytes") > > When e2fsck sees this, it thinks it's a bad sector and tries to write a > block of nulls which overwrites the valid data. Hmm. Block devices shouldn't have issues with s_maxbytes, and I'm surprised that nobody has seen that before. > Device is LVM over 2 x RAID-5 on an old 32bit desktop. > > RO RA SSZ BSZ StartSec Size Device > rw 4096 512 4096 0 9748044840960 /dev/Storage/Main .. and the problem may be as simple as just a missing initialization of s_maxbytes for blockdev_superblock. Does the attcahed trivial one-liner fix things for you? Al, if it really is this simple, how come nobody even noticed? Also, I do wonder if that check in do_generic_file_read() should just unconditionally use MAX_LFS_FILESIZE, since the whole point there is really about the index wrap-around, not about any underlying filesystem limits per se. And that's exactly what MAX_LFS_FILESIZE is - the maximum size that fits in the page index. Linus --001a113d0a8ab4f6f0055770d661 Content-Type: text/plain; charset="US-ASCII"; name="patch.diff" Content-Disposition: attachment; filename="patch.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j6pezfkv0 IGZzL2Jsb2NrX2Rldi5jIHwgMSArCiAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKykKCmRp ZmYgLS1naXQgYS9mcy9ibG9ja19kZXYuYyBiL2ZzL2Jsb2NrX2Rldi5jCmluZGV4IDk5NDFkYzgz NDJkZi4uNGMzODY3YzUyOThhIDEwMDY0NAotLS0gYS9mcy9ibG9ja19kZXYuYworKysgYi9mcy9i bG9ja19kZXYuYwpAQCAtODMwLDYgKzgzMCw3IEBAIHZvaWQgX19pbml0IGJkZXZfY2FjaGVfaW5p dCh2b2lkKQogCWlmIChJU19FUlIoYmRfbW50KSkKIAkJcGFuaWMoIkNhbm5vdCBjcmVhdGUgYmRl diBwc2V1ZG8tZnMiKTsKIAlibG9ja2Rldl9zdXBlcmJsb2NrID0gYmRfbW50LT5tbnRfc2I7ICAg LyogRm9yIHdyaXRlYmFjayAqLworCWJsb2NrZGV2X3N1cGVyYmxvY2stPnNfbWF4Ynl0ZXMgPSBN QVhfTEZTX0ZJTEVTSVpFOwogfQogCiAvKgo= --001a113d0a8ab4f6f0055770d661--