From 480ad01d1139c41d7d35f2249834eee33bce57e5 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Thu, 14 Jun 2018 08:35:23 +0200 Subject: [PATCH] 4.4-stable patches added patches: clarify-and-fix-max_lfs_filesize-macros.patch gpio-no-null-owner.patch --- ...rify-and-fix-max_lfs_filesize-macros.patch | 84 +++++++++++++++++++ queue-4.4/gpio-no-null-owner.patch | 46 ++++++++++ queue-4.4/series | 2 + 3 files changed, 132 insertions(+) create mode 100644 queue-4.4/clarify-and-fix-max_lfs_filesize-macros.patch create mode 100644 queue-4.4/gpio-no-null-owner.patch diff --git a/queue-4.4/clarify-and-fix-max_lfs_filesize-macros.patch b/queue-4.4/clarify-and-fix-max_lfs_filesize-macros.patch new file mode 100644 index 00000000000..2794d1451f8 --- /dev/null +++ b/queue-4.4/clarify-and-fix-max_lfs_filesize-macros.patch @@ -0,0 +1,84 @@ +From 0cc3b0ec23ce4c69e1e890ed2b8d2fa932b14aad Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Sun, 27 Aug 2017 12:12:25 -0700 +Subject: Clarify (and fix) MAX_LFS_FILESIZE macros + +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 diff --git a/queue-4.4/gpio-no-null-owner.patch b/queue-4.4/gpio-no-null-owner.patch new file mode 100644 index 00000000000..dc2b63c73c7 --- /dev/null +++ b/queue-4.4/gpio-no-null-owner.patch @@ -0,0 +1,46 @@ +From 7d18f0a14aa6a0d6bad39111c1fb655f07f71d59 Mon Sep 17 00:00:00 2001 +From: Linus Walleij +Date: Tue, 16 Jan 2018 08:29:50 +0100 +Subject: gpio: No NULL owner + +From: Linus Walleij + +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 +Cc: Daniel Rosenberg +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + diff --git a/queue-4.4/series b/queue-4.4/series index b685510370f..ddb392db675 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -12,3 +12,5 @@ x86-fpu-fix-fnsave-usage-in-eagerfpu-mode.patch x86-fpu-fix-math-emulation-in-eager-fpu-mode.patch af_key-always-verify-length-of-provided-sadb_key.patch x86-crypto-x86-fpu-remove-x86_feature_eager_fpu-ifdef-from-the-crc32c-code.patch +gpio-no-null-owner.patch +clarify-and-fix-max_lfs_filesize-macros.patch -- 2.47.3