Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2000875imm; Thu, 14 Jun 2018 07:16:34 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJVe9y4mTmZaTNMh6GgE9Z5y0lDg9AdVlc8M/6uN19mLllXQTALYqLItXFHLocBbjK0zK/x X-Received: by 2002:a62:90db:: with SMTP id q88-v6mr9778725pfk.186.1528985794405; Thu, 14 Jun 2018 07:16:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528985794; cv=none; d=google.com; s=arc-20160816; b=M8P25DqnueEr1QXOFcxifTJCDD/FCnGOSaMxNbbQbY15f52Ufwluht/2RTL6CYjL32 XoyJ4SNYrRjdmAgL64dMIY09a3zO7vNCWFnTPuHn4o/t9T/CihmCRpQjJob+5u4KV9Ko fzCKnewBImgWcltU+g8EwJUSo4olxtTSBXlr5ydbHywegxc9VQr+LCWOB9/qW5XabhOI aF1cXsxtD6kVn641p3EdFXtetxMBzHtr7YfJyaTcks8Zcya6sz/bpW1FBP3m3VgNps9V wYn2jSt6lBGuZtld0JiwdgXD616TllkG2AqGNkKFfOi35C97hrdrUGMl+cQMmztD+cy6 rTGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=CIKTahkWrL9Tuv4fEOiLoGR+QBT+yqtZO0t9qC7Wu0g=; b=wUjYuMybKyFsYrhlNRlA+0Gks+2bLUtdCUVxA6QCW2AsozXCp8gP489qxIwWIZ6NEE PNR7eieq1QeRFTKhdgRLjNr+rqM/lhDmRB6Ija8CZcJecUmR2urhCGgSENr/MyZ1CKN+ gD5cpj879PlrzhpCZ4rWPbI25M18JGX9Y+MOtvCrRISfoHKHPMqt6IQWy86d93B3rVs2 GP1AbwdcSenmZNuKZUKj8GW9BYDnV8HoWxlfZBu0975s1MCEJVK9AT7k7D+gjeD6o1ZG +u3maa4BaEAQOMtf37la8iEig0k/4J2UlfzxN1DaTALgWTpBJs3L2qBnlRLx8eMR/2VV cOlw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=XstPJ+7e; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n9-v6si4553974pgp.558.2018.06.14.07.16.20; Thu, 14 Jun 2018 07:16:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=XstPJ+7e; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966401AbeFNOPL (ORCPT + 99 others); Thu, 14 Jun 2018 10:15:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:56258 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965100AbeFNOPI (ORCPT ); Thu, 14 Jun 2018 10:15:08 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CA5EF20864; Thu, 14 Jun 2018 14:15:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1528985708; bh=C92cKg7r0hYw5SScMgzUz4RIO7l6K0G/igihewdJhTQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XstPJ+7eL8c5QvQXle83TPnE7tchYvDXDRbTR32rG5Sd96Y37EGuuTwc/5KZsH7RD islNAYXulJz5JyyzaDhILdGM5gD4+/8Tw08I/MQjQLnLOrR5QnZZmNyHcZXrfgRPvB r+guDDUAlKnRGBOJ2ISlFFOsDTqREfOnqE9XU9oM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andreas Dilger , Mark Fasheh , Joel Becker , Dave Kleikamp , Linus Torvalds , Rafael Tinoco Subject: [PATCH 4.4 16/24] Clarify (and fix) MAX_LFS_FILESIZE macros Date: Thu, 14 Jun 2018 16:05:11 +0200 Message-Id: <20180614132725.132674292@linuxfoundation.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180614132724.483802160@linuxfoundation.org> References: <20180614132724.483802160@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Linus Torvalds commit 0cc3b0ec23ce4c69e1e890ed2b8d2fa932b14aad upstream. We have a MAX_LFS_FILESIZE macro that is meant to be filled in by filesystems (and other IO targets) that know they are 64-bit clean and don't have any 32-bit limits in their IO path. It turns out that our 32-bit value for that limit was bogus. On 32-bit, the VM layer is limited by the page cache to only 32-bit index values, but our logic for that was confusing and actually wrong. We used to define that value to (((loff_t)PAGE_SIZE << (BITS_PER_LONG-1))-1) which is actually odd in several ways: it limits the index to 31 bits, and then it limits files so that they can't have data in that last byte of a page that has the highest 31-bit index (ie page index 0x7fffffff). Neither of those limitations make sense. The index is actually the full 32 bit unsigned value, and we can use that whole full page. So the maximum size of the file would logically be "PAGE_SIZE << BITS_PER_LONG". However, we do wan tto avoid the maximum index, because we have code that iterates over the page indexes, and we don't want that code to overflow. So the maximum size of a file on a 32-bit host should actually be one page less than the full 32-bit index. So the actual limit is ULONG_MAX << PAGE_SHIFT. That means that we will not actually be using the page of that last index (ULONG_MAX), but we can grow a file up to that limit. The wrong value of MAX_LFS_FILESIZE actually caused problems for Doug Nazar, who was still using a 32-bit host, but with a 9.7TB 2 x RAID5 volume. It turns out that our old MAX_LFS_FILESIZE was 8TiB (well, one byte less), but the actual true VM limit is one page less than 16TiB. This was invisible until commit c2a9737f45e2 ("vfs,mm: fix a dead loop in truncate_inode_pages_range()"), which started applying that MAX_LFS_FILESIZE limit to block devices too. NOTE! On 64-bit, the page index isn't a limiter at all, and the limit is actually just the offset type itself (loff_t), which is signed. But for clarity, on 64-bit, just use the maximum signed value, and don't make people have to count the number of 'f' characters in the hex constant. So just use LLONG_MAX for the 64-bit case. That was what the value had been before too, just written out as a hex constant. Fixes: c2a9737f45e2 ("vfs,mm: fix a dead loop in truncate_inode_pages_range()") Reported-and-tested-by: Doug Nazar Cc: Andreas Dilger Cc: Mark Fasheh Cc: Joel Becker Cc: Dave Kleikamp Cc: stable@kernel.org Signed-off-by: Linus Torvalds Cc: Rafael Tinoco [backported to 4.4.y due to requests of failed LTP tests - gregkh] Signed-off-by: Greg Kroah-Hartman --- include/linux/fs.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -926,9 +926,9 @@ static inline struct file *get_file(stru /* Page cache limit. The filesystems should put that into their s_maxbytes limits, otherwise bad things can happen in VM. */ #if BITS_PER_LONG==32 -#define MAX_LFS_FILESIZE (((loff_t)PAGE_CACHE_SIZE << (BITS_PER_LONG-1))-1) +#define MAX_LFS_FILESIZE ((loff_t)ULONG_MAX << PAGE_SHIFT) #elif BITS_PER_LONG==64 -#define MAX_LFS_FILESIZE ((loff_t)0x7fffffffffffffffLL) +#define MAX_LFS_FILESIZE ((loff_t)LLONG_MAX) #endif #define FL_POSIX 1