From patchwork Wed Aug 23 19:37:13 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Torvalds X-Patchwork-Id: 9918217 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 CFE42602CB for ; Wed, 23 Aug 2017 19:37:32 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C1B47289EE for ; Wed, 23 Aug 2017 19:37:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B68D528A22; Wed, 23 Aug 2017 19:37:32 +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.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=unavailable 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 68955289EE for ; Wed, 23 Aug 2017 19:37:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932702AbdHWThT (ORCPT ); Wed, 23 Aug 2017 15:37:19 -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 Received: by mail-oi0-f41.google.com with SMTP id j144so11310278oib.1; Wed, 23 Aug 2017 12:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=f5BY+7aUKeYl13d3627KHb2rJ/zkaclxbV/Qd9TTaPM=; b=kpu/r0t6rUkBhjJM7S1raAsIs8G8h3m3721xSx8fpidcOngOor/vA7GP28ev1bnknY ryVU8pTCLstQPNDtQoBb0rTNILhse4FOqeBnhbfPN7f6iEaSz8iX+6Peu14gCp7e7gKw C3OgdPYw9EGAlO6WSAyzHx1G7Z7JUDW5zIez0IBxKVLvJdG3y6jYCbUtWqiNv/IlGdaA Ggslv54iMhdVEaxN4cK9ovAjtxaFQXB9V964Ej3tPThEHhFZzZ93EtVtYj4Qpfrjg+M8 +g9zJKXTzFXD2kU0Ybz//qywMt0547Mzzt/DBTvL8GjiGlXlr7U2QeBVD2a7XeU+/Rwa j4kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=f5BY+7aUKeYl13d3627KHb2rJ/zkaclxbV/Qd9TTaPM=; b=VMF3ZDFSIdlT3p1Hohr8fcFZu6aLse+eisMYjFQe3Hwv1rDQcK6/TiIMeQuhHR0S6j tvc9pB1qD1nmXNMYVdgSEgQWHuKS7cBKL+/s4XNUdTGp9iG0Sdaror3XW9yHKZ35IQ6T pxyygTguCLWAaECBZPk+8W6c2FcurDD/By0QSZvni2obGISOwbZmPmto/BzoosPg8326 NVE6VsF0z41Jnw1kitsdLC6rxypxUne+rDntofBNYP/k6/6EqVMPP4iTpyY9crxcJ5D/ wJHiMAnrpX+RTK/DqvsG3rKeUe2k6nKljzB+iPX+T5uSNw7HJ7OfWgkzrimsWfMtc/3g dPNA== X-Gm-Message-State: AHYfb5iiqzHHJv8o08MzW7Z+wMXOibFjU2/rES2nKOTInaP7liw9P5i0 eSKtRMBiw9GWiHzG6npPWgyODc69FA== X-Received: by 10.202.87.2 with SMTP id l2mr5487391oib.90.1503517033680; Wed, 23 Aug 2017 12:37:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.23.45 with HTTP; Wed, 23 Aug 2017 12:37:13 -0700 (PDT) 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 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 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 fs/block_dev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/block_dev.c b/fs/block_dev.c index 9941dc8342df..4c3867c5298a 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -830,6 +830,7 @@ void __init bdev_cache_init(void) if (IS_ERR(bd_mnt)) panic("Cannot create bdev pseudo-fs"); blockdev_superblock = bd_mnt->mnt_sb; /* For writeback */ + blockdev_superblock->s_maxbytes = MAX_LFS_FILESIZE; } /*