drop some, add some

8 files changed, 313 insertions, 98 deletions

diff --git a/asoc-cs42xx8-add-regcache-mask-dirty.patch b/asoc-cs42xx8-add-regcache-mask-dirty.patch
new file mode 100644
index 0000000..7372a7e
--- /dev/null
+++ b/asoc-cs42xx8-add-regcache-mask-dirty.patch
@@ -0,0 +1,34 @@
+From ad6eecbfc01c987e0253371f274c3872042e4350 Mon Sep 17 00:00:00 2001
+From: "S.j. Wang" <shengjiu.wang@nxp.com>
+Date: Thu, 16 May 2019 06:04:29 +0000
+Subject: ASoC: cs42xx8: Add regcache mask dirty
+
+From: S.j. Wang <shengjiu.wang@nxp.com>
+
+commit ad6eecbfc01c987e0253371f274c3872042e4350 upstream.
+
+Add regcache_mark_dirty before regcache_sync for power
+of codec may be lost at suspend, then all the register
+need to be reconfigured.
+
+Fixes: 0c516b4ff85c ("ASoC: cs42xx8: Add codec driver
+support for CS42448/CS42888")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/soc/codecs/cs42xx8.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/soc/codecs/cs42xx8.c
++++ b/sound/soc/codecs/cs42xx8.c
+@@ -560,6 +560,7 @@ static int cs42xx8_runtime_resume(struct
+ 	msleep(5);
+ 
+ 	regcache_cache_only(cs42xx8->regmap, false);
++	regcache_mark_dirty(cs42xx8->regmap);
+ 
+ 	ret = regcache_sync(cs42xx8->regmap);
+ 	if (ret) {
diff --git a/bcache-fix-stack-corruption-by-preceding_key.patch b/bcache-fix-stack-corruption-by-preceding_key.patch
new file mode 100644
index 0000000..21f3beb
--- /dev/null
+++ b/bcache-fix-stack-corruption-by-preceding_key.patch
@@ -0,0 +1,127 @@
+From 31b90956b124240aa8c63250243ae1a53585c5e2 Mon Sep 17 00:00:00 2001
+From: Coly Li <colyli@suse.de>
+Date: Mon, 10 Jun 2019 06:13:34 +0800
+Subject: bcache: fix stack corruption by PRECEDING_KEY()
+
+From: Coly Li <colyli@suse.de>
+
+commit 31b90956b124240aa8c63250243ae1a53585c5e2 upstream.
+
+Recently people report bcache code compiled with gcc9 is broken, one of
+the buggy behavior I observe is that two adjacent 4KB I/Os should merge
+into one but they don't. Finally it turns out to be a stack corruption
+caused by macro PRECEDING_KEY().
+
+See how PRECEDING_KEY() is defined in bset.h,
+437 #define PRECEDING_KEY(_k)                                       \
+438 ({                                                              \
+439         struct bkey *_ret = NULL;                               \
+440                                                                 \
+441         if (KEY_INODE(_k) || KEY_OFFSET(_k)) {                  \
+442                 _ret = &KEY(KEY_INODE(_k), KEY_OFFSET(_k), 0);  \
+443                                                                 \
+444                 if (!_ret->low)                                 \
+445                         _ret->high--;                           \
+446                 _ret->low--;                                    \
+447         }                                                       \
+448                                                                 \
+449         _ret;                                                   \
+450 })
+
+At line 442, _ret points to address of a on-stack variable combined by
+KEY(), the life range of this on-stack variable is in line 442-446,
+once _ret is returned to bch_btree_insert_key(), the returned address
+points to an invalid stack address and this address is overwritten in
+the following called bch_btree_iter_init(). Then argument 'search' of
+bch_btree_iter_init() points to some address inside stackframe of
+bch_btree_iter_init(), exact address depends on how the compiler
+allocates stack space. Now the stack is corrupted.
+
+Fixes: 0eacac22034c ("bcache: PRECEDING_KEY()")
+Signed-off-by: Coly Li <colyli@suse.de>
+Reviewed-by: Rolf Fokkens <rolf@rolffokkens.nl>
+Reviewed-by: Pierre JUHEN <pierre.juhen@orange.fr>
+Tested-by: Shenghui Wang <shhuiw@foxmail.com>
+Tested-by: Pierre JUHEN <pierre.juhen@orange.fr>
+Cc: Kent Overstreet <kent.overstreet@gmail.com>
+Cc: Nix <nix@esperi.org.uk>
+Cc: stable@vger.kernel.org
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/bcache/bset.c |   16 +++++++++++++---
+ drivers/md/bcache/bset.h |   34 ++++++++++++++++++++--------------
+ 2 files changed, 33 insertions(+), 17 deletions(-)
+
+--- a/drivers/md/bcache/bset.c
++++ b/drivers/md/bcache/bset.c
+@@ -823,12 +823,22 @@ unsigned bch_btree_insert_key(struct btr
+ 	struct bset *i = bset_tree_last(b)->data;
+ 	struct bkey *m, *prev = NULL;
+ 	struct btree_iter iter;
++	struct bkey preceding_key_on_stack = ZERO_KEY;
++	struct bkey *preceding_key_p = &preceding_key_on_stack;
+ 
+ 	BUG_ON(b->ops->is_extents && !KEY_SIZE(k));
+ 
+-	m = bch_btree_iter_init(b, &iter, b->ops->is_extents
+-				? PRECEDING_KEY(&START_KEY(k))
+-				: PRECEDING_KEY(k));
++	/*
++	 * If k has preceding key, preceding_key_p will be set to address
++	 *  of k's preceding key; otherwise preceding_key_p will be set
++	 * to NULL inside preceding_key().
++	 */
++	if (b->ops->is_extents)
++		preceding_key(&START_KEY(k), &preceding_key_p);
++	else
++		preceding_key(k, &preceding_key_p);
++
++	m = bch_btree_iter_init(b, &iter, preceding_key_p);
+ 
+ 	if (b->ops->insert_fixup(b, k, &iter, replace_key))
+ 		return status;
+--- a/drivers/md/bcache/bset.h
++++ b/drivers/md/bcache/bset.h
+@@ -417,20 +417,26 @@ static inline bool bch_cut_back(const st
+ 	return __bch_cut_back(where, k);
+ }
+ 
+-#define PRECEDING_KEY(_k)					\
+-({								\
+-	struct bkey *_ret = NULL;				\
+-								\
+-	if (KEY_INODE(_k) || KEY_OFFSET(_k)) {			\
+-		_ret = &KEY(KEY_INODE(_k), KEY_OFFSET(_k), 0);	\
+-								\
+-		if (!_ret->low)					\
+-			_ret->high--;				\
+-		_ret->low--;					\
+-	}							\
+-								\
+-	_ret;							\
+-})
++/*
++ * Pointer '*preceding_key_p' points to a memory object to store preceding
++ * key of k. If the preceding key does not exist, set '*preceding_key_p' to
++ * NULL. So the caller of preceding_key() needs to take care of memory
++ * which '*preceding_key_p' pointed to before calling preceding_key().
++ * Currently the only caller of preceding_key() is bch_btree_insert_key(),
++ * and it points to an on-stack variable, so the memory release is handled
++ * by stackframe itself.
++ */
++static inline void preceding_key(struct bkey *k, struct bkey **preceding_key_p)
++{
++	if (KEY_INODE(k) || KEY_OFFSET(k)) {
++		(**preceding_key_p) = KEY(KEY_INODE(k), KEY_OFFSET(k), 0);
++		if (!(*preceding_key_p)->low)
++			(*preceding_key_p)->high--;
++		(*preceding_key_p)->low--;
++	} else {
++		(*preceding_key_p) = NULL;
++	}
++}
+ 
+ static inline bool bch_ptr_invalid(struct btree_keys *b, const struct bkey *k)
+ {
diff --git a/futex-fix-futex-lock-the-wrong-page.patch b/futex-fix-futex-lock-the-wrong-page.patch
deleted file mode 100644
index 4f01f6a..0000000
--- a/futex-fix-futex-lock-the-wrong-page.patch
+++ /dev/null
@@ -1,41 +0,0 @@
-From zhangxiaoxu5@huawei.com  Wed Jun 12 13:03:33 2019
-From: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
-Date: Wed, 12 Jun 2019 09:54:25 +0800
-Subject: futex: Fix futex lock the wrong page
-To: <tglx@linutronix.de>, <mingo@redhat.com>, <peterz@infradead.org>, <dvhart@infradead.org>, <linux-kernel@vger.kernel.org>, <zhangxiaoxu5@huawei.com>
-Message-ID: <1560304465-68966-1-git-send-email-zhangxiaoxu5@huawei.com>
-
-From: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
-
-The upstram commit 65d8fc777f6d ("futex: Remove requirement
-for lock_page() in get_futex_key()") use variable 'page' as
-the page head, when merge it to stable branch, the variable
-`page_head` is page head.
-
-In the stable branch, the variable `page` not means the page
-head, when lock the page head, we should lock 'page_head',
-rather than 'page'.
-
-It maybe lead a hung task problem.
-
-Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
-Cc: stable@vger.kernel.org
-Cc: Thomas Gleixner <tglx@linutronix.de>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- kernel/futex.c |    4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
---- a/kernel/futex.c
-+++ b/kernel/futex.c
-@@ -516,8 +516,8 @@ again:
- 		 * applies. If this is really a shmem page then the page lock
- 		 * will prevent unexpected transitions.
- 		 */
--		lock_page(page);
--		shmem_swizzled = PageSwapCache(page) || page->mapping;
-+		lock_page(page_head);
-+		shmem_swizzled = PageSwapCache(page_head) || page_head->mapping;
- 		unlock_page(page_head);
- 		put_page(page_head);
- 
diff --git a/i2c-acorn-fix-i2c-warning.patch b/i2c-acorn-fix-i2c-warning.patch
new file mode 100644
index 0000000..7d73487
--- /dev/null
+++ b/i2c-acorn-fix-i2c-warning.patch
@@ -0,0 +1,33 @@
+From ca21f851cc9643af049226d57fabc3c883ea648e Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@armlinux.org.uk>
+Date: Tue, 11 Jun 2019 17:48:18 +0100
+Subject: i2c: acorn: fix i2c warning
+
+From: Russell King <rmk+kernel@armlinux.org.uk>
+
+commit ca21f851cc9643af049226d57fabc3c883ea648e upstream.
+
+The Acorn i2c driver (for RiscPC) triggers the "i2c adapter has no name"
+warning in the I2C core driver, resulting in the RTC being inaccessible.
+Fix this.
+
+Fixes: 2236baa75f70 ("i2c: Sanity checks on adapter registration")
+Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/busses/i2c-acorn.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/i2c/busses/i2c-acorn.c
++++ b/drivers/i2c/busses/i2c-acorn.c
+@@ -83,6 +83,7 @@ static struct i2c_algo_bit_data ioc_data
+ 
+ static struct i2c_adapter ioc_ops = {
+ 	.nr			= 0,
++	.name			= "ioc",
+ 	.algo_data		= &ioc_data,
+ };
+ 
diff --git a/libata-extend-quirks-for-the-st1000lm024-drives-with-nolpm-quirk.patch b/libata-extend-quirks-for-the-st1000lm024-drives-with-nolpm-quirk.patch
new file mode 100644
index 0000000..5983db3
--- /dev/null
+++ b/libata-extend-quirks-for-the-st1000lm024-drives-with-nolpm-quirk.patch
@@ -0,0 +1,42 @@
+From 31f6264e225fb92cf6f4b63031424f20797c297d Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Tue, 11 Jun 2019 16:32:59 +0200
+Subject: libata: Extend quirks for the ST1000LM024 drives with NOLPM quirk
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 31f6264e225fb92cf6f4b63031424f20797c297d upstream.
+
+We've received a bugreport that using LPM with ST1000LM024 drives leads
+to system lockups. So it seems that these models are buggy in more then
+1 way. Add NOLPM quirk to the existing quirks entry for BROKEN_FPDMA_AA.
+
+BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1571330
+Cc: stable@vger.kernel.org
+Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/libata-core.c |    9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -4174,9 +4174,12 @@ static const struct ata_blacklist_entry
+ 	{ "ST3320[68]13AS",	"SD1[5-9]",	ATA_HORKAGE_NONCQ |
+ 						ATA_HORKAGE_FIRMWARE_WARN },
+ 
+-	/* drives which fail FPDMA_AA activation (some may freeze afterwards) */
+-	{ "ST1000LM024 HN-M101MBB", "2AR10001",	ATA_HORKAGE_BROKEN_FPDMA_AA },
+-	{ "ST1000LM024 HN-M101MBB", "2BA30001",	ATA_HORKAGE_BROKEN_FPDMA_AA },
++	/* drives which fail FPDMA_AA activation (some may freeze afterwards)
++	   the ST disks also have LPM issues */
++	{ "ST1000LM024 HN-M101MBB", "2AR10001",	ATA_HORKAGE_BROKEN_FPDMA_AA |
++						ATA_HORKAGE_NOLPM, },
++	{ "ST1000LM024 HN-M101MBB", "2BA30001",	ATA_HORKAGE_BROKEN_FPDMA_AA |
++						ATA_HORKAGE_NOLPM, },
+ 	{ "VB0250EAVER",	"HPG7",		ATA_HORKAGE_BROKEN_FPDMA_AA },
+ 
+ 	/* Blacklist entries taken from Silicon Image 3124/3132
diff --git a/revert-bluetooth-align-minimum-encryption-key-size-for-le-and-br-edr-connections.patch b/revert-bluetooth-align-minimum-encryption-key-size-for-le-and-br-edr-connections.patch
deleted file mode 100644
index 5729b91..0000000
--- a/revert-bluetooth-align-minimum-encryption-key-size-for-le-and-br-edr-connections.patch
+++ /dev/null
@@ -1,55 +0,0 @@
-From cf24ec6fe7cbd3bd0722cb9e7d845b4b818f2275 Mon Sep 17 00:00:00 2001
-From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-Date: Thu, 13 Jun 2019 09:28:42 +0200
-Subject: Revert "Bluetooth: Align minimum encryption key size for LE and BR/EDR connections"
-
-From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
-This reverts commit b16a6c99f88c16c9b4f736226b736d0c53320614 which is
-commit d5bb334a8e171b262e48f378bd2096c0ea458265 upstream.
-
-Lots of people have reported issues with this patch, and as there does
-not seem to be a fix going into Linus's kernel tree any time soon,
-revert the commit in the stable trees so as to get people's machines
-working properly again.
-
-Reported-by: Vasily Khoruzhick <anarsoul@gmail.com>
-Reported-by: Hans de Goede <hdegoede@redhat.com>
-Cc: Jeremy Cline <jeremy@jcline.org>
-Cc: Marcel Holtmann <marcel@holtmann.org>
-Cc: Johan Hedberg <johan.hedberg@intel.com>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- include/net/bluetooth/hci_core.h |    3 ---
- net/bluetooth/hci_conn.c         |    8 --------
- 2 files changed, 11 deletions(-)
-
---- a/include/net/bluetooth/hci_core.h
-+++ b/include/net/bluetooth/hci_core.h
-@@ -145,9 +145,6 @@ struct oob_data {
- 
- #define HCI_MAX_SHORT_NAME_LENGTH	10
- 
--/* Min encryption key size to match with SMP */
--#define HCI_MIN_ENC_KEY_SIZE		7
--
- /* Default LE RPA expiry time, 15 minutes */
- #define HCI_DEFAULT_RPA_TIMEOUT		(15 * 60)
- 
---- a/net/bluetooth/hci_conn.c
-+++ b/net/bluetooth/hci_conn.c
-@@ -932,14 +932,6 @@ int hci_conn_check_link_mode(struct hci_
- 	    !test_bit(HCI_CONN_ENCRYPT, &conn->flags))
- 		return 0;
- 
--	/* The minimum encryption key size needs to be enforced by the
--	 * host stack before establishing any L2CAP connections. The
--	 * specification in theory allows a minimum of 1, but to align
--	 * BR/EDR and LE transports, a minimum of 7 is chosen.
--	 */
--	if (conn->enc_key_size < HCI_MIN_ENC_KEY_SIZE)
--		return 0;
--
- 	return 1;
- }
- 
diff --git a/series b/series
index 152da6a..a4ff96d 100644
--- a/series
+++ b/series
@@ -1,3 +1,6 @@
-futex-fix-futex-lock-the-wrong-page.patch
-revert-bluetooth-align-minimum-encryption-key-size-for-le-and-br-edr-connections.patch
 alsa-seq-cover-unsubscribe_port-in-list_mutex.patch
+libata-extend-quirks-for-the-st1000lm024-drives-with-nolpm-quirk.patch
+signal-ptrace-don-t-leak-unitialized-kernel-memory-with-ptrace_peek_siginfo.patch
+i2c-acorn-fix-i2c-warning.patch
+bcache-fix-stack-corruption-by-preceding_key.patch
+asoc-cs42xx8-add-regcache-mask-dirty.patch
diff --git a/signal-ptrace-don-t-leak-unitialized-kernel-memory-with-ptrace_peek_siginfo.patch b/signal-ptrace-don-t-leak-unitialized-kernel-memory-with-ptrace_peek_siginfo.patch
new file mode 100644
index 0000000..70bd47c
--- /dev/null
+++ b/signal-ptrace-don-t-leak-unitialized-kernel-memory-with-ptrace_peek_siginfo.patch
@@ -0,0 +1,72 @@
+From f6e2aa91a46d2bc79fce9b93a988dbe7655c90c0 Mon Sep 17 00:00:00 2001
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+Date: Tue, 28 May 2019 18:46:37 -0500
+Subject: signal/ptrace: Don't leak unitialized kernel memory with PTRACE_PEEK_SIGINFO
+
+From: Eric W. Biederman <ebiederm@xmission.com>
+
+commit f6e2aa91a46d2bc79fce9b93a988dbe7655c90c0 upstream.
+
+Recently syzbot in conjunction with KMSAN reported that
+ptrace_peek_siginfo can copy an uninitialized siginfo to userspace.
+Inspecting ptrace_peek_siginfo confirms this.
+
+The problem is that off when initialized from args.off can be
+initialized to a negaive value.  At which point the "if (off >= 0)"
+test to see if off became negative fails because off started off
+negative.
+
+Prevent the core problem by adding a variable found that is only true
+if a siginfo is found and copied to a temporary in preparation for
+being copied to userspace.
+
+Prevent args.off from being truncated when being assigned to off by
+testing that off is <= the maximum possible value of off.  Convert off
+to an unsigned long so that we should not have to truncate args.off,
+we have well defined overflow behavior so if we add another check we
+won't risk fighting undefined compiler behavior, and so that we have a
+type whose maximum value is easy to test for.
+
+Cc: Andrei Vagin <avagin@gmail.com>
+Cc: stable@vger.kernel.org
+Reported-by: syzbot+0d602a1b0d8c95bdf299@syzkaller.appspotmail.com
+Fixes: 84c751bd4aeb ("ptrace: add ability to retrieve signals without removing from a queue (v4)")
+Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/ptrace.c |    9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/kernel/ptrace.c
++++ b/kernel/ptrace.c
+@@ -664,6 +664,10 @@ static int ptrace_peek_siginfo(struct ta
+ 	if (arg.nr < 0)
+ 		return -EINVAL;
+ 
++	/* Ensure arg.off fits in an unsigned long */
++	if (arg.off > ULONG_MAX)
++		return 0;
++
+ 	if (arg.flags & PTRACE_PEEKSIGINFO_SHARED)
+ 		pending = &child->signal->shared_pending;
+ 	else
+@@ -671,7 +675,8 @@ static int ptrace_peek_siginfo(struct ta
+ 
+ 	for (i = 0; i < arg.nr; ) {
+ 		siginfo_t info;
+-		s32 off = arg.off + i;
++		unsigned long off = arg.off + i;
++		bool found = false;
+ 
+ 		spin_lock_irq(&child->sighand->siglock);
+ 		list_for_each_entry(q, &pending->list, list) {
+@@ -682,7 +687,7 @@ static int ptrace_peek_siginfo(struct ta
+ 		}
+ 		spin_unlock_irq(&child->sighand->siglock);
+ 
+-		if (off >= 0) /* beyond the end of the list */
++		if (!found) /* beyond the end of the list */
+ 			break;
+ 
+ #ifdef CONFIG_COMPAT