From: Greg Kroah-Hartman Date: Mon, 12 Jun 2017 09:18:33 +0000 (+0200) Subject: 3.18-stable patches X-Git-Tag: v3.18.57~22 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=359e742fa885f6745fc43ec0d1d11ae1f67e2b04;p=thirdparty%2Fkernel%2Fstable-queue.git 3.18-stable patches added patches: btrfs-fix-memory-leak-in-update_space_info-failure-path.patch btrfs-use-correct-types-for-page-indices-in-btrfs_page_exists_in_range.patch cpuset-consider-dying-css-as-offline.patch dmaengine-ep93xx-always-start-from-base0.patch drivers-char-random-add-get_random_long.patch ext4-fix-seek_hole.patch ext4-keep-existing-extra-fields-when-inode-expands.patch iio-proximity-as3935-fix-as3935_int-mask.patch random-properly-align-get_random_int_hash.patch stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch staging-lustre-lov-remove-set_fs-call-from-lov_getstripe.patch usb-chipidea-debug-check-before-accessing-ci_role.patch usb-chipidea-udc-fix-null-pointer-dereference-if-udc_start-failed.patch usb-gadget-f_mass_storage-serialize-wake-and-sleep-execution.patch --- diff --git a/queue-3.18/btrfs-fix-memory-leak-in-update_space_info-failure-path.patch b/queue-3.18/btrfs-fix-memory-leak-in-update_space_info-failure-path.patch new file mode 100644 index 00000000000..5743b0770e4 --- /dev/null +++ b/queue-3.18/btrfs-fix-memory-leak-in-update_space_info-failure-path.patch @@ -0,0 +1,32 @@ +From 896533a7da929136d0432713f02a3edffece2826 Mon Sep 17 00:00:00 2001 +From: Jeff Mahoney +Date: Wed, 17 May 2017 09:49:37 -0400 +Subject: btrfs: fix memory leak in update_space_info failure path + +From: Jeff Mahoney + +commit 896533a7da929136d0432713f02a3edffece2826 upstream. + +If we fail to add the space_info kobject, we'll leak the memory +for the percpu counter. + +Fixes: 6ab0a2029c (btrfs: publish allocation data in sysfs) +Signed-off-by: Jeff Mahoney +Reviewed-by: Liu Bo +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/extent-tree.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/btrfs/extent-tree.c ++++ b/fs/btrfs/extent-tree.c +@@ -3509,6 +3509,7 @@ static int update_space_info(struct btrf + info->space_info_kobj, "%s", + alloc_name(found->flags)); + if (ret) { ++ percpu_counter_destroy(&found->total_bytes_pinned); + kfree(found); + return ret; + } diff --git a/queue-3.18/btrfs-use-correct-types-for-page-indices-in-btrfs_page_exists_in_range.patch b/queue-3.18/btrfs-use-correct-types-for-page-indices-in-btrfs_page_exists_in_range.patch new file mode 100644 index 00000000000..aec8e24980a --- /dev/null +++ b/queue-3.18/btrfs-use-correct-types-for-page-indices-in-btrfs_page_exists_in_range.patch @@ -0,0 +1,64 @@ +From cc2b702c52094b637a351d7491ac5200331d0445 Mon Sep 17 00:00:00 2001 +From: David Sterba +Date: Fri, 12 May 2017 01:03:52 +0200 +Subject: btrfs: use correct types for page indices in btrfs_page_exists_in_range + +From: David Sterba + +commit cc2b702c52094b637a351d7491ac5200331d0445 upstream. + +Variables start_idx and end_idx are supposed to hold a page index +derived from the file offsets. The int type is not the right one though, +offsets larger than 1 << 44 will get silently trimmed off the high bits. +(1 << 44 is 16TiB) + +What can go wrong, if start is below the boundary and end gets trimmed: +- if there's a page after start, we'll find it (radix_tree_gang_lookup_slot) +- the final check "if (page->index <= end_idx)" will unexpectedly fail + +The function will return false, ie. "there's no page in the range", +although there is at least one. + +btrfs_page_exists_in_range is used to prevent races in: + +* in hole punching, where we make sure there are not pages in the + truncated range, otherwise we'll wait for them to finish and redo + truncation, but we're going to replace the pages with holes anyway so + the only problem is the intermediate state + +* lock_extent_direct: we want to make sure there are no pages before we + lock and start DIO, to prevent stale data reads + +For practical occurence of the bug, there are several constaints. The +file must be quite large, the affected range must cross the 16TiB +boundary and the internal state of the file pages and pending operations +must match. Also, we must not have started any ordered data in the +range, otherwise we don't even reach the buggy function check. + +DIO locking tries hard in several places to avoid deadlocks with +buffered IO and avoids waiting for ranges. The worst consequence seems +to be stale data read. + +CC: Liu Bo +Fixes: fc4adbff823f7 ("btrfs: Drop EXTENT_UPTODATE check in hole punching and direct locking") +Reviewed-by: Liu Bo +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/inode.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/fs/btrfs/inode.c ++++ b/fs/btrfs/inode.c +@@ -6920,8 +6920,8 @@ bool btrfs_page_exists_in_range(struct i + int found = false; + void **pagep = NULL; + struct page *page = NULL; +- int start_idx; +- int end_idx; ++ unsigned long start_idx; ++ unsigned long end_idx; + + start_idx = start >> PAGE_CACHE_SHIFT; + diff --git a/queue-3.18/cpuset-consider-dying-css-as-offline.patch b/queue-3.18/cpuset-consider-dying-css-as-offline.patch new file mode 100644 index 00000000000..2a2f5d24977 --- /dev/null +++ b/queue-3.18/cpuset-consider-dying-css-as-offline.patch @@ -0,0 +1,79 @@ +From 41c25707d21716826e3c1f60967f5550610ec1c9 Mon Sep 17 00:00:00 2001 +From: Tejun Heo +Date: Wed, 24 May 2017 12:03:48 -0400 +Subject: cpuset: consider dying css as offline + +From: Tejun Heo + +commit 41c25707d21716826e3c1f60967f5550610ec1c9 upstream. + +In most cases, a cgroup controller don't care about the liftimes of +cgroups. For the controller, a css becomes online when ->css_online() +is called on it and offline when ->css_offline() is called. + +However, cpuset is special in that the user interface it exposes cares +whether certain cgroups exist or not. Combined with the RCU delay +between cgroup removal and css offlining, this can lead to user +visible behavior oddities where operations which should succeed after +cgroup removals fail for some time period. The effects of cgroup +removals are delayed when seen from userland. + +This patch adds css_is_dying() which tests whether offline is pending +and updates is_cpuset_online() so that the function returns false also +while offline is pending. This gets rid of the userland visible +delays. + +Signed-off-by: Tejun Heo +Reported-by: Daniel Jordan +Link: http://lkml.kernel.org/r/327ca1f5-7957-fbb9-9e5f-9ba149d40ba2@oracle.com +Signed-off-by: Tejun Heo +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/cgroup.h | 20 ++++++++++++++++++++ + kernel/cpuset.c | 4 ++-- + 2 files changed, 22 insertions(+), 2 deletions(-) + +--- a/include/linux/cgroup.h ++++ b/include/linux/cgroup.h +@@ -148,6 +148,26 @@ static inline bool css_tryget_online(str + } + + /** ++ * css_is_dying - test whether the specified css is dying ++ * @css: target css ++ * ++ * Test whether @css is in the process of offlining or already offline. In ++ * most cases, ->css_online() and ->css_offline() callbacks should be ++ * enough; however, the actual offline operations are RCU delayed and this ++ * test returns %true also when @css is scheduled to be offlined. ++ * ++ * This is useful, for example, when the use case requires synchronous ++ * behavior with respect to cgroup removal. cgroup removal schedules css ++ * offlining but the css can seem alive while the operation is being ++ * delayed. If the delay affects user visible semantics, this test can be ++ * used to resolve the situation. ++ */ ++static inline bool css_is_dying(struct cgroup_subsys_state *css) ++{ ++ return !(css->flags & CSS_NO_REF) && percpu_ref_is_dying(&css->refcnt); ++} ++ ++/** + * css_put - put a css reference + * @css: target css + * +--- a/kernel/cpuset.c ++++ b/kernel/cpuset.c +@@ -174,9 +174,9 @@ typedef enum { + } cpuset_flagbits_t; + + /* convenient tests for these bits */ +-static inline bool is_cpuset_online(const struct cpuset *cs) ++static inline bool is_cpuset_online(struct cpuset *cs) + { +- return test_bit(CS_ONLINE, &cs->flags); ++ return test_bit(CS_ONLINE, &cs->flags) && !css_is_dying(&cs->css); + } + + static inline int is_cpu_exclusive(const struct cpuset *cs) diff --git a/queue-3.18/dmaengine-ep93xx-always-start-from-base0.patch b/queue-3.18/dmaengine-ep93xx-always-start-from-base0.patch new file mode 100644 index 00000000000..d11e26e5f41 --- /dev/null +++ b/queue-3.18/dmaengine-ep93xx-always-start-from-base0.patch @@ -0,0 +1,34 @@ +From 0037ae47812b1f431cc602100d1d51f37d77b61e Mon Sep 17 00:00:00 2001 +From: Alexander Sverdlin +Date: Mon, 22 May 2017 16:05:22 +0200 +Subject: dmaengine: ep93xx: Always start from BASE0 + +From: Alexander Sverdlin + +commit 0037ae47812b1f431cc602100d1d51f37d77b61e upstream. + +The current buffer is being reset to zero on device_free_chan_resources() +but not on device_terminate_all(). It could happen that HW is restarted and +expects BASE0 to be used, but the driver is not synchronized and will start +from BASE1. One solution is to reset the buffer explicitly in +m2p_hw_setup(). + +Signed-off-by: Alexander Sverdlin +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/dma/ep93xx_dma.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/dma/ep93xx_dma.c ++++ b/drivers/dma/ep93xx_dma.c +@@ -325,6 +325,8 @@ static int m2p_hw_setup(struct ep93xx_dm + | M2P_CONTROL_ENABLE; + m2p_set_control(edmac, control); + ++ edmac->buffer = 0; ++ + return 0; + } + diff --git a/queue-3.18/drivers-char-random-add-get_random_long.patch b/queue-3.18/drivers-char-random-add-get_random_long.patch new file mode 100644 index 00000000000..0d928381042 --- /dev/null +++ b/queue-3.18/drivers-char-random-add-get_random_long.patch @@ -0,0 +1,103 @@ +From ec9ee4acd97c0039a61c0ae4f12705767ae62153 Mon Sep 17 00:00:00 2001 +From: Daniel Cashman +Date: Fri, 26 Feb 2016 15:19:34 -0800 +Subject: drivers: char: random: add get_random_long() + +From: Daniel Cashman + +commit ec9ee4acd97c0039a61c0ae4f12705767ae62153 upstream. + +Commit d07e22597d1d ("mm: mmap: add new /proc tunable for mmap_base +ASLR") added the ability to choose from a range of values to use for +entropy count in generating the random offset to the mmap_base address. + +The maximum value on this range was set to 32 bits for 64-bit x86 +systems, but this value could be increased further, requiring more than +the 32 bits of randomness provided by get_random_int(), as is already +possible for arm64. Add a new function: get_random_long() which more +naturally fits with the mmap usage of get_random_int() but operates +exactly the same as get_random_int(). + +Also, fix the shifting constant in mmap_rnd() to be an unsigned long so +that values greater than 31 bits generate an appropriate mask without +overflow. This is especially important on x86, as its shift instruction +uses a 5-bit mask for the shift operand, which meant that any value for +mmap_rnd_bits over 31 acts as a no-op and effectively disables mmap_base +randomization. + +Finally, replace calls to get_random_int() with get_random_long() where +appropriate. + +This patch (of 2): + +Add get_random_long(). + +Signed-off-by: Daniel Cashman +Acked-by: Kees Cook +Cc: "Theodore Ts'o" +Cc: Arnd Bergmann +Cc: Greg Kroah-Hartman +Cc: Catalin Marinas +Cc: Will Deacon +Cc: Ralf Baechle +Cc: Benjamin Herrenschmidt +Cc: Paul Mackerras +Cc: Michael Ellerman +Cc: David S. Miller +Cc: Thomas Gleixner +Cc: Ingo Molnar +Cc: H. Peter Anvin +Cc: Al Viro +Cc: Nick Kralevich +Cc: Jeff Vander Stoep +Cc: Mark Salyzyn +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/random.c | 22 ++++++++++++++++++++++ + include/linux/random.h | 1 + + 2 files changed, 23 insertions(+) + +--- a/drivers/char/random.c ++++ b/drivers/char/random.c +@@ -1741,6 +1741,28 @@ unsigned int get_random_int(void) + EXPORT_SYMBOL(get_random_int); + + /* ++ * Same as get_random_int(), but returns unsigned long. ++ */ ++unsigned long get_random_long(void) ++{ ++ __u32 *hash; ++ unsigned long ret; ++ ++ if (arch_get_random_long(&ret)) ++ return ret; ++ ++ hash = get_cpu_var(get_random_int_hash); ++ ++ hash[0] += current->pid + jiffies + random_get_entropy(); ++ md5_transform(hash, random_int_secret); ++ ret = *(unsigned long *)hash; ++ put_cpu_var(get_random_int_hash); ++ ++ return ret; ++} ++EXPORT_SYMBOL(get_random_long); ++ ++/* + * randomize_range() returns a start address such that + * + * [...... .....] +--- a/include/linux/random.h ++++ b/include/linux/random.h +@@ -23,6 +23,7 @@ extern const struct file_operations rand + #endif + + unsigned int get_random_int(void); ++unsigned long get_random_long(void); + unsigned long randomize_range(unsigned long start, unsigned long end, unsigned long len); + + u32 prandom_u32(void); diff --git a/queue-3.18/ext4-fix-seek_hole.patch b/queue-3.18/ext4-fix-seek_hole.patch new file mode 100644 index 00000000000..73314df9d9b --- /dev/null +++ b/queue-3.18/ext4-fix-seek_hole.patch @@ -0,0 +1,143 @@ +From 7d95eddf313c88b24f99d4ca9c2411a4b82fef33 Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Sun, 21 May 2017 22:33:23 -0400 +Subject: ext4: fix SEEK_HOLE + +From: Jan Kara + +commit 7d95eddf313c88b24f99d4ca9c2411a4b82fef33 upstream. + +Currently, SEEK_HOLE implementation in ext4 may both return that there's +a hole at some offset although that offset already has data and skip +some holes during a search for the next hole. The first problem is +demostrated by: + +xfs_io -c "falloc 0 256k" -c "pwrite 0 56k" -c "seek -h 0" file +wrote 57344/57344 bytes at offset 0 +56 KiB, 14 ops; 0.0000 sec (2.054 GiB/sec and 538461.5385 ops/sec) +Whence Result +HOLE 0 + +Where we can see that SEEK_HOLE wrongly returned offset 0 as containing +a hole although we have written data there. The second problem can be +demonstrated by: + +xfs_io -c "falloc 0 256k" -c "pwrite 0 56k" -c "pwrite 128k 8k" + -c "seek -h 0" file + +wrote 57344/57344 bytes at offset 0 +56 KiB, 14 ops; 0.0000 sec (1.978 GiB/sec and 518518.5185 ops/sec) +wrote 8192/8192 bytes at offset 131072 +8 KiB, 2 ops; 0.0000 sec (2 GiB/sec and 500000.0000 ops/sec) +Whence Result +HOLE 139264 + +Where we can see that hole at offsets 56k..128k has been ignored by the +SEEK_HOLE call. + +The underlying problem is in the ext4_find_unwritten_pgoff() which is +just buggy. In some cases it fails to update returned offset when it +finds a hole (when no pages are found or when the first found page has +higher index than expected), in some cases conditions for detecting hole +are just missing (we fail to detect a situation where indices of +returned pages are not contiguous). + +Fix ext4_find_unwritten_pgoff() to properly detect non-contiguous page +indices and also handle all cases where we got less pages then expected +in one place and handle it properly there. + +Fixes: c8c0df241cc2719b1262e627f999638411934f60 +CC: Zheng Liu +Signed-off-by: Jan Kara +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/file.c | 50 ++++++++++++++------------------------------------ + 1 file changed, 14 insertions(+), 36 deletions(-) + +--- a/fs/ext4/file.c ++++ b/fs/ext4/file.c +@@ -303,47 +303,27 @@ static int ext4_find_unwritten_pgoff(str + num = min_t(pgoff_t, end - index, PAGEVEC_SIZE); + nr_pages = pagevec_lookup(&pvec, inode->i_mapping, index, + (pgoff_t)num); +- if (nr_pages == 0) { +- if (whence == SEEK_DATA) +- break; +- +- BUG_ON(whence != SEEK_HOLE); +- /* +- * If this is the first time to go into the loop and +- * offset is not beyond the end offset, it will be a +- * hole at this offset +- */ +- if (lastoff == startoff || lastoff < endoff) +- found = 1; ++ if (nr_pages == 0) + break; +- } +- +- /* +- * If this is the first time to go into the loop and +- * offset is smaller than the first page offset, it will be a +- * hole at this offset. +- */ +- if (lastoff == startoff && whence == SEEK_HOLE && +- lastoff < page_offset(pvec.pages[0])) { +- found = 1; +- break; +- } + + for (i = 0; i < nr_pages; i++) { + struct page *page = pvec.pages[i]; + struct buffer_head *bh, *head; + + /* +- * If the current offset is not beyond the end of given +- * range, it will be a hole. ++ * If current offset is smaller than the page offset, ++ * there is a hole at this offset. + */ +- if (lastoff < endoff && whence == SEEK_HOLE && +- page->index > end) { ++ if (whence == SEEK_HOLE && lastoff < endoff && ++ lastoff < page_offset(pvec.pages[i])) { + found = 1; + *offset = lastoff; + goto out; + } + ++ if (page->index > end) ++ goto out; ++ + lock_page(page); + + if (unlikely(page->mapping != inode->i_mapping)) { +@@ -383,20 +363,18 @@ static int ext4_find_unwritten_pgoff(str + unlock_page(page); + } + +- /* +- * The no. of pages is less than our desired, that would be a +- * hole in there. +- */ +- if (nr_pages < num && whence == SEEK_HOLE) { +- found = 1; +- *offset = lastoff; ++ /* The no. of pages is less than our desired, we are done. */ ++ if (nr_pages < num) + break; +- } + + index = pvec.pages[i - 1]->index + 1; + pagevec_release(&pvec); + } while (index <= end); + ++ if (whence == SEEK_HOLE && lastoff < endoff) { ++ found = 1; ++ *offset = lastoff; ++ } + out: + pagevec_release(&pvec); + return found; diff --git a/queue-3.18/ext4-keep-existing-extra-fields-when-inode-expands.patch b/queue-3.18/ext4-keep-existing-extra-fields-when-inode-expands.patch new file mode 100644 index 00000000000..0f2de769008 --- /dev/null +++ b/queue-3.18/ext4-keep-existing-extra-fields-when-inode-expands.patch @@ -0,0 +1,35 @@ +From 887a9730614727c4fff7cb756711b190593fc1df Mon Sep 17 00:00:00 2001 +From: Konstantin Khlebnikov +Date: Sun, 21 May 2017 22:36:23 -0400 +Subject: ext4: keep existing extra fields when inode expands + +From: Konstantin Khlebnikov + +commit 887a9730614727c4fff7cb756711b190593fc1df upstream. + +ext4_expand_extra_isize() should clear only space between old and new +size. + +Fixes: 6dd4ee7cab7e # v2.6.23 +Signed-off-by: Konstantin Khlebnikov +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/inode.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/fs/ext4/inode.c ++++ b/fs/ext4/inode.c +@@ -4830,8 +4830,9 @@ static int ext4_expand_extra_isize(struc + /* No extended attributes present */ + if (!ext4_test_inode_state(inode, EXT4_STATE_XATTR) || + header->h_magic != cpu_to_le32(EXT4_XATTR_MAGIC)) { +- memset((void *)raw_inode + EXT4_GOOD_OLD_INODE_SIZE, 0, +- new_extra_isize); ++ memset((void *)raw_inode + EXT4_GOOD_OLD_INODE_SIZE + ++ EXT4_I(inode)->i_extra_isize, 0, ++ new_extra_isize - EXT4_I(inode)->i_extra_isize); + EXT4_I(inode)->i_extra_isize = new_extra_isize; + return 0; + } diff --git a/queue-3.18/iio-proximity-as3935-fix-as3935_int-mask.patch b/queue-3.18/iio-proximity-as3935-fix-as3935_int-mask.patch new file mode 100644 index 00000000000..aba5c11a6c0 --- /dev/null +++ b/queue-3.18/iio-proximity-as3935-fix-as3935_int-mask.patch @@ -0,0 +1,36 @@ +From 275292d3a3d62670b1b13484707b74e5239b4bb0 Mon Sep 17 00:00:00 2001 +From: Matt Ranostay +Date: Thu, 27 Apr 2017 00:52:32 -0700 +Subject: iio: proximity: as3935: fix AS3935_INT mask + +From: Matt Ranostay + +commit 275292d3a3d62670b1b13484707b74e5239b4bb0 upstream. + +AS3935 interrupt mask has been incorrect so valid lightning events +would never trigger an buffer event. Also noise interrupt should be +BIT(0). + +Fixes: 24ddb0e4bba4 ("iio: Add AS3935 lightning sensor support") +Signed-off-by: Matt Ranostay +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/proximity/as3935.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/iio/proximity/as3935.c ++++ b/drivers/iio/proximity/as3935.c +@@ -40,9 +40,9 @@ + #define AS3935_AFE_PWR_BIT BIT(0) + + #define AS3935_INT 0x03 +-#define AS3935_INT_MASK 0x07 ++#define AS3935_INT_MASK 0x0f + #define AS3935_EVENT_INT BIT(3) +-#define AS3935_NOISE_INT BIT(1) ++#define AS3935_NOISE_INT BIT(0) + + #define AS3935_DATA 0x07 + #define AS3935_DATA_MASK 0x3F diff --git a/queue-3.18/random-properly-align-get_random_int_hash.patch b/queue-3.18/random-properly-align-get_random_int_hash.patch new file mode 100644 index 00000000000..7dbf0ba1d9f --- /dev/null +++ b/queue-3.18/random-properly-align-get_random_int_hash.patch @@ -0,0 +1,40 @@ +From b1132deac01c2332d234fa821a70022796b79182 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Wed, 4 May 2016 21:08:39 -0400 +Subject: random: properly align get_random_int_hash + +From: Eric Biggers + +commit b1132deac01c2332d234fa821a70022796b79182 upstream. + +get_random_long() reads from the get_random_int_hash array using an +unsigned long pointer. For this code to be guaranteed correct on all +architectures, the array must be aligned to an unsigned long boundary. + +Signed-off-by: Eric Biggers +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/random.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/char/random.c ++++ b/drivers/char/random.c +@@ -1714,13 +1714,15 @@ int random_int_secret_init(void) + return 0; + } + ++static DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash) ++ __aligned(sizeof(unsigned long)); ++ + /* + * Get a random word for internal kernel use only. Similar to urandom but + * with the goal of minimal entropy pool depletion. As a result, the random + * value is not cryptographically secure but for several uses the cost of + * depleting entropy is too high + */ +-static DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash); + unsigned int get_random_int(void) + { + __u32 *hash; diff --git a/queue-3.18/series b/queue-3.18/series index df034f47713..f02d722179f 100644 --- a/queue-3.18/series +++ b/queue-3.18/series @@ -13,3 +13,17 @@ nfsd4-fix-null-dereference-on-replay.patch kvm-async_pf-fix-rcu_irq_enter-with-irqs-enabled.patch kvm-cpuid-fix-read-write-out-of-bounds-vulnerability-in-cpuid-emulation.patch arm-kvm-allow-unaligned-accesses-at-hyp.patch +dmaengine-ep93xx-always-start-from-base0.patch +ext4-fix-seek_hole.patch +ext4-keep-existing-extra-fields-when-inode-expands.patch +usb-gadget-f_mass_storage-serialize-wake-and-sleep-execution.patch +usb-chipidea-udc-fix-null-pointer-dereference-if-udc_start-failed.patch +usb-chipidea-debug-check-before-accessing-ci_role.patch +staging-lustre-lov-remove-set_fs-call-from-lov_getstripe.patch +iio-proximity-as3935-fix-as3935_int-mask.patch +drivers-char-random-add-get_random_long.patch +random-properly-align-get_random_int_hash.patch +stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch +cpuset-consider-dying-css-as-offline.patch +btrfs-use-correct-types-for-page-indices-in-btrfs_page_exists_in_range.patch +btrfs-fix-memory-leak-in-update_space_info-failure-path.patch diff --git a/queue-3.18/stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch b/queue-3.18/stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch new file mode 100644 index 00000000000..ec681cee264 --- /dev/null +++ b/queue-3.18/stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch @@ -0,0 +1,41 @@ +From 5ea30e4e58040cfd6434c2f33dc3ea76e2c15b05 Mon Sep 17 00:00:00 2001 +From: Daniel Micay +Date: Thu, 4 May 2017 09:32:09 -0400 +Subject: stackprotector: Increase the per-task stack canary's random range from 32 bits to 64 bits on 64-bit platforms + +From: Daniel Micay + +commit 5ea30e4e58040cfd6434c2f33dc3ea76e2c15b05 upstream. + +The stack canary is an 'unsigned long' and should be fully initialized to +random data rather than only 32 bits of random data. + +Signed-off-by: Daniel Micay +Acked-by: Arjan van de Ven +Acked-by: Rik van Riel +Acked-by: Kees Cook +Cc: Arjan van Ven +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: kernel-hardening@lists.openwall.com +Cc: stable@vger.kernel.org +Link: http://lkml.kernel.org/r/20170504133209.3053-1-danielmicay@gmail.com +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/fork.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/fork.c ++++ b/kernel/fork.c +@@ -338,7 +338,7 @@ static struct task_struct *dup_task_stru + set_task_stack_end_magic(tsk); + + #ifdef CONFIG_CC_STACKPROTECTOR +- tsk->stack_canary = get_random_int(); ++ tsk->stack_canary = get_random_long(); + #endif + + /* diff --git a/queue-3.18/staging-lustre-lov-remove-set_fs-call-from-lov_getstripe.patch b/queue-3.18/staging-lustre-lov-remove-set_fs-call-from-lov_getstripe.patch new file mode 100644 index 00000000000..e245228c093 --- /dev/null +++ b/queue-3.18/staging-lustre-lov-remove-set_fs-call-from-lov_getstripe.patch @@ -0,0 +1,58 @@ +From 0a33252e060e97ed3fbdcec9517672f1e91aaef3 Mon Sep 17 00:00:00 2001 +From: Oleg Drokin +Date: Fri, 26 May 2017 23:40:33 -0400 +Subject: staging/lustre/lov: remove set_fs() call from lov_getstripe() + +From: Oleg Drokin + +commit 0a33252e060e97ed3fbdcec9517672f1e91aaef3 upstream. + +lov_getstripe() calls set_fs(KERNEL_DS) so that it can handle a struct +lov_user_md pointer from user- or kernel-space. This changes the +behavior of copy_from_user() on SPARC and may result in a misaligned +access exception which in turn oopses the kernel. In fact the +relevant argument to lov_getstripe() is never called with a +kernel-space pointer and so changing the address limits is unnecessary +and so we remove the calls to save, set, and restore the address +limits. + +Signed-off-by: John L. Hammond +Reviewed-on: http://review.whamcloud.com/6150 +Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3221 +Reviewed-by: Andreas Dilger +Reviewed-by: Li Wei +Signed-off-by: Oleg Drokin +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/staging/lustre/lustre/lov/lov_pack.c | 9 --------- + 1 file changed, 9 deletions(-) + +--- a/drivers/staging/lustre/lustre/lov/lov_pack.c ++++ b/drivers/staging/lustre/lustre/lov/lov_pack.c +@@ -420,18 +420,10 @@ int lov_getstripe(struct obd_export *exp + struct lov_mds_md *lmmk = NULL; + int rc, lmm_size; + int lum_size; +- mm_segment_t seg; + + if (!lsm) + return -ENODATA; + +- /* +- * "Switch to kernel segment" to allow copying from kernel space by +- * copy_{to,from}_user(). +- */ +- seg = get_fs(); +- set_fs(KERNEL_DS); +- + /* we only need the header part from user space to get lmm_magic and + * lmm_stripe_count, (the header part is common to v1 and v3) */ + lum_size = sizeof(struct lov_user_md_v1); +@@ -507,6 +499,5 @@ int lov_getstripe(struct obd_export *exp + + obd_free_diskmd(exp, &lmmk); + out_set: +- set_fs(seg); + return rc; + } diff --git a/queue-3.18/usb-chipidea-debug-check-before-accessing-ci_role.patch b/queue-3.18/usb-chipidea-debug-check-before-accessing-ci_role.patch new file mode 100644 index 00000000000..a6a76644952 --- /dev/null +++ b/queue-3.18/usb-chipidea-debug-check-before-accessing-ci_role.patch @@ -0,0 +1,31 @@ +From 0340ff83cd4475261e7474033a381bc125b45244 Mon Sep 17 00:00:00 2001 +From: Michael Thalmeier +Date: Thu, 18 May 2017 16:14:14 +0200 +Subject: usb: chipidea: debug: check before accessing ci_role + +From: Michael Thalmeier + +commit 0340ff83cd4475261e7474033a381bc125b45244 upstream. + +ci_role BUGs when the role is >= CI_ROLE_END. + +Signed-off-by: Michael Thalmeier +Signed-off-by: Peter Chen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/chipidea/debug.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/usb/chipidea/debug.c ++++ b/drivers/usb/chipidea/debug.c +@@ -290,7 +290,8 @@ static int ci_role_show(struct seq_file + { + struct ci_hdrc *ci = s->private; + +- seq_printf(s, "%s\n", ci_role(ci)->name); ++ if (ci->role != CI_ROLE_END) ++ seq_printf(s, "%s\n", ci_role(ci)->name); + + return 0; + } diff --git a/queue-3.18/usb-chipidea-udc-fix-null-pointer-dereference-if-udc_start-failed.patch b/queue-3.18/usb-chipidea-udc-fix-null-pointer-dereference-if-udc_start-failed.patch new file mode 100644 index 00000000000..8f5c7ff0d0e --- /dev/null +++ b/queue-3.18/usb-chipidea-udc-fix-null-pointer-dereference-if-udc_start-failed.patch @@ -0,0 +1,83 @@ +From aa1f058d7d9244423b8c5a75b9484b1115df7f02 Mon Sep 17 00:00:00 2001 +From: Jisheng Zhang +Date: Mon, 24 Apr 2017 12:35:51 +0000 +Subject: usb: chipidea: udc: fix NULL pointer dereference if udc_start failed + +From: Jisheng Zhang + +commit aa1f058d7d9244423b8c5a75b9484b1115df7f02 upstream. + +Fix below NULL pointer dereference. we set ci->roles[CI_ROLE_GADGET] +too early in ci_hdrc_gadget_init(), if udc_start() fails due to some +reason, the ci->roles[CI_ROLE_GADGET] check in ci_hdrc_gadget_destroy +can't protect us. + +We fix this issue by only setting ci->roles[CI_ROLE_GADGET] if +udc_start() succeed. + +[ 1.398550] Unable to handle kernel NULL pointer dereference at +virtual address 00000000 +... +[ 1.448600] PC is at dma_pool_free+0xb8/0xf0 +[ 1.453012] LR is at dma_pool_free+0x28/0xf0 +[ 2.113369] [] dma_pool_free+0xb8/0xf0 +[ 2.118857] [] destroy_eps+0x4c/0x68 +[ 2.124165] [] ci_hdrc_gadget_destroy+0x28/0x50 +[ 2.130461] [] ci_hdrc_probe+0x588/0x7e8 +[ 2.136129] [] platform_drv_probe+0x50/0xb8 +[ 2.142066] [] driver_probe_device+0x1fc/0x2a8 +[ 2.148270] [] __device_attach_driver+0x9c/0xf8 +[ 2.154563] [] bus_for_each_drv+0x58/0x98 +[ 2.160317] [] __device_attach+0xc4/0x138 +[ 2.166072] [] device_initial_probe+0x10/0x18 +[ 2.172185] [] bus_probe_device+0x94/0xa0 +[ 2.177940] [] device_add+0x3f0/0x560 +[ 2.183337] [] platform_device_add+0x180/0x240 +[ 2.189541] [] ci_hdrc_add_device+0x440/0x4f8 +[ 2.195654] [] ci_hdrc_usb2_probe+0x13c/0x2d8 +[ 2.201769] [] platform_drv_probe+0x50/0xb8 +[ 2.207705] [] driver_probe_device+0x1fc/0x2a8 +[ 2.213910] [] __driver_attach+0xac/0xb0 +[ 2.219575] [] bus_for_each_dev+0x60/0xa0 +[ 2.225329] [] driver_attach+0x20/0x28 +[ 2.230816] [] bus_add_driver+0x1d0/0x238 +[ 2.236571] [] driver_register+0x60/0xf8 +[ 2.242237] [] __platform_driver_register+0x44/0x50 +[ 2.248891] [] ci_hdrc_usb2_driver_init+0x18/0x20 +[ 2.255365] [] do_one_initcall+0x38/0x128 +[ 2.261121] [] kernel_init_freeable+0x1ac/0x250 +[ 2.267414] [] kernel_init+0x10/0x100 +[ 2.272810] [] ret_from_fork+0x10/0x50 + +Fixes: 3f124d233e97 ("usb: chipidea: add role init and destroy APIs") +Signed-off-by: Jisheng Zhang +Signed-off-by: Peter Chen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/chipidea/udc.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/drivers/usb/chipidea/udc.c ++++ b/drivers/usb/chipidea/udc.c +@@ -1892,6 +1892,7 @@ static void udc_id_switch_for_host(struc + int ci_hdrc_gadget_init(struct ci_hdrc *ci) + { + struct ci_role_driver *rdrv; ++ int ret; + + if (!hw_read(ci, CAP_DCCPARAMS, DCCPARAMS_DC)) + return -ENXIO; +@@ -1904,7 +1905,10 @@ int ci_hdrc_gadget_init(struct ci_hdrc * + rdrv->stop = udc_id_switch_for_host; + rdrv->irq = udc_irq; + rdrv->name = "gadget"; +- ci->roles[CI_ROLE_GADGET] = rdrv; + +- return udc_start(ci); ++ ret = udc_start(ci); ++ if (!ret) ++ ci->roles[CI_ROLE_GADGET] = rdrv; ++ ++ return ret; + } diff --git a/queue-3.18/usb-gadget-f_mass_storage-serialize-wake-and-sleep-execution.patch b/queue-3.18/usb-gadget-f_mass_storage-serialize-wake-and-sleep-execution.patch new file mode 100644 index 00000000000..da92d76b95c --- /dev/null +++ b/queue-3.18/usb-gadget-f_mass_storage-serialize-wake-and-sleep-execution.patch @@ -0,0 +1,98 @@ +From dc9217b69dd6089dcfeb86ed4b3c671504326087 Mon Sep 17 00:00:00 2001 +From: Thinh Nguyen +Date: Thu, 11 May 2017 17:26:48 -0700 +Subject: usb: gadget: f_mass_storage: Serialize wake and sleep execution + +From: Thinh Nguyen + +commit dc9217b69dd6089dcfeb86ed4b3c671504326087 upstream. + +f_mass_storage has a memorry barrier issue with the sleep and wake +functions that can cause a deadlock. This results in intermittent hangs +during MSC file transfer. The host will reset the device after receiving +no response to resume the transfer. This issue is seen when dwc3 is +processing 2 transfer-in-progress events at the same time, invoking +completion handlers for CSW and CBW. Also this issue occurs depending on +the system timing and latency. + +To increase the chance to hit this issue, you can force dwc3 driver to +wait and process those 2 events at once by adding a small delay (~100us) +in dwc3_check_event_buf() whenever the request is for CSW and read the +event count again. Avoid debugging with printk and ftrace as extra +delays and memory barrier will mask this issue. + +Scenario which can lead to failure: +----------------------------------- +1) The main thread sleeps and waits for the next command in + get_next_command(). +2) bulk_in_complete() wakes up main thread for CSW. +3) bulk_out_complete() tries to wake up the running main thread for CBW. +4) thread_wakeup_needed is not loaded with correct value in + sleep_thread(). +5) Main thread goes to sleep again. + +The pattern is shown below. Note the 2 critical variables. + * common->thread_wakeup_needed + * bh->state + + CPU 0 (sleep_thread) CPU 1 (wakeup_thread) + ============================== =============================== + + bh->state = BH_STATE_FULL; + smp_wmb(); + thread_wakeup_needed = 0; thread_wakeup_needed = 1; + smp_rmb(); + if (bh->state != BH_STATE_FULL) + sleep again ... + +As pointed out by Alan Stern, this is an R-pattern issue. The issue can +be seen when there are two wakeups in quick succession. The +thread_wakeup_needed can be overwritten in sleep_thread, and the read of +the bh->state maybe reordered before the write to thread_wakeup_needed. + +This patch applies full memory barrier smp_mb() in both sleep_thread() +and wakeup_thread() to ensure the order which the thread_wakeup_needed +and bh->state are written and loaded. + +However, a better solution in the future would be to use wait_queue +method that takes care of managing memory barrier between waker and +waiter. + +Acked-by: Alan Stern +Signed-off-by: Thinh Nguyen +Signed-off-by: Felipe Balbi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/gadget/function/f_mass_storage.c | 13 +++++++++++-- + 1 file changed, 11 insertions(+), 2 deletions(-) + +--- a/drivers/usb/gadget/function/f_mass_storage.c ++++ b/drivers/usb/gadget/function/f_mass_storage.c +@@ -400,7 +400,11 @@ static int fsg_set_halt(struct fsg_dev * + /* Caller must hold fsg->lock */ + static void wakeup_thread(struct fsg_common *common) + { +- smp_wmb(); /* ensure the write of bh->state is complete */ ++ /* ++ * Ensure the reading of thread_wakeup_needed ++ * and the writing of bh->state are completed ++ */ ++ smp_mb(); + /* Tell the main thread that something has happened */ + common->thread_wakeup_needed = 1; + if (common->thread_task) +@@ -621,7 +625,12 @@ static int sleep_thread(struct fsg_commo + } + __set_current_state(TASK_RUNNING); + common->thread_wakeup_needed = 0; +- smp_rmb(); /* ensure the latest bh->state is visible */ ++ ++ /* ++ * Ensure the writing of thread_wakeup_needed ++ * and the reading of bh->state are completed ++ */ ++ smp_mb(); + return rc; + } +