--- /dev/null
+From 0cc3b0ec23ce4c69e1e890ed2b8d2fa932b14aad Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Sun, 27 Aug 2017 12:12:25 -0700
+Subject: Clarify (and fix) MAX_LFS_FILESIZE macros
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+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 <nazard@nazar.ca>
+Cc: Andreas Dilger <adilger@dilger.ca>
+Cc: Mark Fasheh <mfasheh@versity.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Dave Kleikamp <shaggy@kernel.org>
+Cc: stable@kernel.org
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Rafael Tinoco <rafael.tinoco@linaro.org>
+[backported to 4.4.y due to requests of failed LTP tests - gregkh]
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From 7d18f0a14aa6a0d6bad39111c1fb655f07f71d59 Mon Sep 17 00:00:00 2001
+From: Linus Walleij <linus.walleij@linaro.org>
+Date: Tue, 16 Jan 2018 08:29:50 +0100
+Subject: gpio: No NULL owner
+
+From: Linus Walleij <linus.walleij@linaro.org>
+
+commit 7d18f0a14aa6a0d6bad39111c1fb655f07f71d59 upstream.
+
+Sometimes a GPIO is fetched with NULL as parent device, and
+that is just fine. So under these circumstances, avoid using
+dev_name() to provide a name for the GPIO line.
+
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Cc: Daniel Rosenberg <drosen@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpiolib.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -2117,6 +2117,8 @@ struct gpio_desc *__must_check gpiod_get
+ struct gpio_desc *desc = NULL;
+ int status;
+ enum gpio_lookup_flags lookupflags = 0;
++ /* Maybe we have a device name, maybe not */
++ const char *devname = dev ? dev_name(dev) : "?";
+
+ dev_dbg(dev, "GPIO lookup for consumer %s\n", con_id);
+
+@@ -2145,8 +2147,11 @@ struct gpio_desc *__must_check gpiod_get
+ return desc;
+ }
+
+- /* If a connection label was passed use that, else use the device name as label */
+- status = gpiod_request(desc, con_id ? con_id : dev_name(dev));
++ /*
++ * If a connection label was passed use that, else attempt to use
++ * the device name as label
++ */
++ status = gpiod_request(desc, con_id ? con_id : devname);
+ if (status < 0)
+ return ERR_PTR(status);
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
