--- /dev/null
+From 896533a7da929136d0432713f02a3edffece2826 Mon Sep 17 00:00:00 2001
+From: Jeff Mahoney <jeffm@suse.com>
+Date: Wed, 17 May 2017 09:49:37 -0400
+Subject: btrfs: fix memory leak in update_space_info failure path
+
+From: Jeff Mahoney <jeffm@suse.com>
+
+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 <jeffm@suse.com>
+Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From cc2b702c52094b637a351d7491ac5200331d0445 Mon Sep 17 00:00:00 2001
+From: David Sterba <dsterba@suse.com>
+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 <dsterba@suse.com>
+
+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 <bo.li.liu@oracle.com>
+Fixes: fc4adbff823f7 ("btrfs: Drop EXTENT_UPTODATE check in hole punching and direct locking")
+Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+
--- /dev/null
+From 41c25707d21716826e3c1f60967f5550610ec1c9 Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Wed, 24 May 2017 12:03:48 -0400
+Subject: cpuset: consider dying css as offline
+
+From: Tejun Heo <tj@kernel.org>
+
+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 <tj@kernel.org>
+Reported-by: Daniel Jordan <daniel.m.jordan@oracle.com>
+Link: http://lkml.kernel.org/r/327ca1f5-7957-fbb9-9e5f-9ba149d40ba2@oracle.com
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From 0037ae47812b1f431cc602100d1d51f37d77b61e Mon Sep 17 00:00:00 2001
+From: Alexander Sverdlin <alexander.sverdlin@gmail.com>
+Date: Mon, 22 May 2017 16:05:22 +0200
+Subject: dmaengine: ep93xx: Always start from BASE0
+
+From: Alexander Sverdlin <alexander.sverdlin@gmail.com>
+
+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 <alexander.sverdlin@gmail.com>
+Signed-off-by: Vinod Koul <vinod.koul@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
--- /dev/null
+From ec9ee4acd97c0039a61c0ae4f12705767ae62153 Mon Sep 17 00:00:00 2001
+From: Daniel Cashman <dcashman@android.com>
+Date: Fri, 26 Feb 2016 15:19:34 -0800
+Subject: drivers: char: random: add get_random_long()
+
+From: Daniel Cashman <dcashman@android.com>
+
+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 <dcashman@android.com>
+Acked-by: Kees Cook <keescook@chromium.org>
+Cc: "Theodore Ts'o" <tytso@mit.edu>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Will Deacon <will.deacon@arm.com>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Cc: Paul Mackerras <paulus@samba.org>
+Cc: Michael Ellerman <mpe@ellerman.id.au>
+Cc: David S. Miller <davem@davemloft.net>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Nick Kralevich <nnk@google.com>
+Cc: Jeff Vander Stoep <jeffv@google.com>
+Cc: Mark Salyzyn <salyzyn@android.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+ *
+ * [...... <range> .....]
+--- 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);
--- /dev/null
+From 7d95eddf313c88b24f99d4ca9c2411a4b82fef33 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Sun, 21 May 2017 22:33:23 -0400
+Subject: ext4: fix SEEK_HOLE
+
+From: Jan Kara <jack@suse.cz>
+
+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 <wenqing.lz@taobao.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 887a9730614727c4fff7cb756711b190593fc1df Mon Sep 17 00:00:00 2001
+From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
+Date: Sun, 21 May 2017 22:36:23 -0400
+Subject: ext4: keep existing extra fields when inode expands
+
+From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
+
+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 <khlebnikov@yandex-team.ru>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 275292d3a3d62670b1b13484707b74e5239b4bb0 Mon Sep 17 00:00:00 2001
+From: Matt Ranostay <matt.ranostay@konsulko.com>
+Date: Thu, 27 Apr 2017 00:52:32 -0700
+Subject: iio: proximity: as3935: fix AS3935_INT mask
+
+From: Matt Ranostay <matt.ranostay@konsulko.com>
+
+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 <matt.ranostay@konsulko.com>
+Signed-off-by: Jonathan Cameron <jic23@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From b1132deac01c2332d234fa821a70022796b79182 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers3@gmail.com>
+Date: Wed, 4 May 2016 21:08:39 -0400
+Subject: random: properly align get_random_int_hash
+
+From: Eric Biggers <ebiggers3@gmail.com>
+
+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 <ebiggers3@gmail.com>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
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
--- /dev/null
+From 5ea30e4e58040cfd6434c2f33dc3ea76e2c15b05 Mon Sep 17 00:00:00 2001
+From: Daniel Micay <danielmicay@gmail.com>
+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 <danielmicay@gmail.com>
+
+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 <danielmicay@gmail.com>
+Acked-by: Arjan van de Ven <arjan@linux.intel.com>
+Acked-by: Rik van Riel <riel@redhat.com>
+Acked-by: Kees Cook <keescook@chromium.org>
+Cc: Arjan van Ven <arjan@linux.intel.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+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 <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+
+ /*
--- /dev/null
+From 0a33252e060e97ed3fbdcec9517672f1e91aaef3 Mon Sep 17 00:00:00 2001
+From: Oleg Drokin <green@linuxhacker.ru>
+Date: Fri, 26 May 2017 23:40:33 -0400
+Subject: staging/lustre/lov: remove set_fs() call from lov_getstripe()
+
+From: Oleg Drokin <green@linuxhacker.ru>
+
+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 <john.hammond@intel.com>
+Reviewed-on: http://review.whamcloud.com/6150
+Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3221
+Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
+Reviewed-by: Li Wei <wei.g.li@intel.com>
+Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 0340ff83cd4475261e7474033a381bc125b45244 Mon Sep 17 00:00:00 2001
+From: Michael Thalmeier <michael.thalmeier@hale.at>
+Date: Thu, 18 May 2017 16:14:14 +0200
+Subject: usb: chipidea: debug: check before accessing ci_role
+
+From: Michael Thalmeier <michael.thalmeier@hale.at>
+
+commit 0340ff83cd4475261e7474033a381bc125b45244 upstream.
+
+ci_role BUGs when the role is >= CI_ROLE_END.
+
+Signed-off-by: Michael Thalmeier <michael.thalmeier@hale.at>
+Signed-off-by: Peter Chen <peter.chen@nxp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From aa1f058d7d9244423b8c5a75b9484b1115df7f02 Mon Sep 17 00:00:00 2001
+From: Jisheng Zhang <jszhang@marvell.com>
+Date: Mon, 24 Apr 2017 12:35:51 +0000
+Subject: usb: chipidea: udc: fix NULL pointer dereference if udc_start failed
+
+From: Jisheng Zhang <jszhang@marvell.com>
+
+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] [<ffffff80081817d8>] dma_pool_free+0xb8/0xf0
+[ 2.118857] [<ffffff800841209c>] destroy_eps+0x4c/0x68
+[ 2.124165] [<ffffff8008413770>] ci_hdrc_gadget_destroy+0x28/0x50
+[ 2.130461] [<ffffff800840fa30>] ci_hdrc_probe+0x588/0x7e8
+[ 2.136129] [<ffffff8008380fb8>] platform_drv_probe+0x50/0xb8
+[ 2.142066] [<ffffff800837f494>] driver_probe_device+0x1fc/0x2a8
+[ 2.148270] [<ffffff800837f68c>] __device_attach_driver+0x9c/0xf8
+[ 2.154563] [<ffffff800837d570>] bus_for_each_drv+0x58/0x98
+[ 2.160317] [<ffffff800837f174>] __device_attach+0xc4/0x138
+[ 2.166072] [<ffffff800837f738>] device_initial_probe+0x10/0x18
+[ 2.172185] [<ffffff800837e58c>] bus_probe_device+0x94/0xa0
+[ 2.177940] [<ffffff800837c560>] device_add+0x3f0/0x560
+[ 2.183337] [<ffffff8008380d20>] platform_device_add+0x180/0x240
+[ 2.189541] [<ffffff800840f0e8>] ci_hdrc_add_device+0x440/0x4f8
+[ 2.195654] [<ffffff8008414194>] ci_hdrc_usb2_probe+0x13c/0x2d8
+[ 2.201769] [<ffffff8008380fb8>] platform_drv_probe+0x50/0xb8
+[ 2.207705] [<ffffff800837f494>] driver_probe_device+0x1fc/0x2a8
+[ 2.213910] [<ffffff800837f5ec>] __driver_attach+0xac/0xb0
+[ 2.219575] [<ffffff800837d4b0>] bus_for_each_dev+0x60/0xa0
+[ 2.225329] [<ffffff800837ec80>] driver_attach+0x20/0x28
+[ 2.230816] [<ffffff800837e880>] bus_add_driver+0x1d0/0x238
+[ 2.236571] [<ffffff800837fdb0>] driver_register+0x60/0xf8
+[ 2.242237] [<ffffff8008380ef4>] __platform_driver_register+0x44/0x50
+[ 2.248891] [<ffffff80086fd440>] ci_hdrc_usb2_driver_init+0x18/0x20
+[ 2.255365] [<ffffff8008082950>] do_one_initcall+0x38/0x128
+[ 2.261121] [<ffffff80086e0d00>] kernel_init_freeable+0x1ac/0x250
+[ 2.267414] [<ffffff800852f0b8>] kernel_init+0x10/0x100
+[ 2.272810] [<ffffff8008082680>] ret_from_fork+0x10/0x50
+
+Fixes: 3f124d233e97 ("usb: chipidea: add role init and destroy APIs")
+Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
+Signed-off-by: Peter Chen <peter.chen@nxp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From dc9217b69dd6089dcfeb86ed4b3c671504326087 Mon Sep 17 00:00:00 2001
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Date: Thu, 11 May 2017 17:26:48 -0700
+Subject: usb: gadget: f_mass_storage: Serialize wake and sleep execution
+
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+
+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 <stern@rowland.harvard.edu>
+Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
