* [PATCH 4.9 01/83] HID: Add 044f:b320 ThrustMaster, Inc. 2 in 1 DT
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
@ 2019-09-04 17:52 ` Greg Kroah-Hartman
2019-09-04 17:52 ` [PATCH 4.9 02/83] MIPS: kernel: only use i8253 clocksource with periodic clockevent Greg Kroah-Hartman
` (87 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ilya Trukhanov, Jiri Kosina, Sasha Levin
[ Upstream commit 65f11c72780fa9d598df88def045ccb6a885cf80 ]
Enable force feedback for the Thrustmaster Dual Trigger 2 in 1 Rumble Force
gamepad. Compared to other Thrustmaster devices, left and right rumble
motors here are swapped.
Signed-off-by: Ilya Trukhanov <lahvuun@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-tmff.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/hid/hid-tmff.c b/drivers/hid/hid-tmff.c
index b83376077d722..cfa0cb22c9b3c 100644
--- a/drivers/hid/hid-tmff.c
+++ b/drivers/hid/hid-tmff.c
@@ -34,6 +34,8 @@
#include "hid-ids.h"
+#define THRUSTMASTER_DEVICE_ID_2_IN_1_DT 0xb320
+
static const signed short ff_rumble[] = {
FF_RUMBLE,
-1
@@ -88,6 +90,7 @@ static int tmff_play(struct input_dev *dev, void *data,
struct hid_field *ff_field = tmff->ff_field;
int x, y;
int left, right; /* Rumbling */
+ int motor_swap;
switch (effect->type) {
case FF_CONSTANT:
@@ -112,6 +115,13 @@ static int tmff_play(struct input_dev *dev, void *data,
ff_field->logical_minimum,
ff_field->logical_maximum);
+ /* 2-in-1 strong motor is left */
+ if (hid->product == THRUSTMASTER_DEVICE_ID_2_IN_1_DT) {
+ motor_swap = left;
+ left = right;
+ right = motor_swap;
+ }
+
dbg_hid("(left,right)=(%08x, %08x)\n", left, right);
ff_field->value[0] = left;
ff_field->value[1] = right;
@@ -238,6 +248,8 @@ static const struct hid_device_id tm_devices[] = {
.driver_data = (unsigned long)ff_rumble },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb304), /* FireStorm Dual Power 2 (and 3) */
.driver_data = (unsigned long)ff_rumble },
+ { HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, THRUSTMASTER_DEVICE_ID_2_IN_1_DT), /* Dual Trigger 2-in-1 */
+ .driver_data = (unsigned long)ff_rumble },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb323), /* Dual Trigger 3-in-1 (PC Mode) */
.driver_data = (unsigned long)ff_rumble },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb324), /* Dual Trigger 3-in-1 (PS3 Mode) */
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 02/83] MIPS: kernel: only use i8253 clocksource with periodic clockevent
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
2019-09-04 17:52 ` [PATCH 4.9 01/83] HID: Add 044f:b320 ThrustMaster, Inc. 2 in 1 DT Greg Kroah-Hartman
@ 2019-09-04 17:52 ` Greg Kroah-Hartman
2019-09-04 17:52 ` [PATCH 4.9 03/83] netfilter: ebtables: fix a memory leak bug in compat Greg Kroah-Hartman
` (86 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thomas Bogendoerfer, Paul Burton,
Ralf Baechle, James Hogan, linux-mips, Sasha Levin
[ Upstream commit a07e3324538a989b7cdbf2c679be6a7f9df2544f ]
i8253 clocksource needs a free running timer. This could only
be used, if i8253 clockevent is set up as periodic.
Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/mips/kernel/i8253.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kernel/i8253.c b/arch/mips/kernel/i8253.c
index c5bc344fc745c..73039746ae364 100644
--- a/arch/mips/kernel/i8253.c
+++ b/arch/mips/kernel/i8253.c
@@ -31,7 +31,8 @@ void __init setup_pit_timer(void)
static int __init init_pit_clocksource(void)
{
- if (num_possible_cpus() > 1) /* PIT does not scale! */
+ if (num_possible_cpus() > 1 || /* PIT does not scale! */
+ !clockevent_state_periodic(&i8253_clockevent))
return 0;
return clocksource_i8253_init();
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 03/83] netfilter: ebtables: fix a memory leak bug in compat
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
2019-09-04 17:52 ` [PATCH 4.9 01/83] HID: Add 044f:b320 ThrustMaster, Inc. 2 in 1 DT Greg Kroah-Hartman
2019-09-04 17:52 ` [PATCH 4.9 02/83] MIPS: kernel: only use i8253 clocksource with periodic clockevent Greg Kroah-Hartman
@ 2019-09-04 17:52 ` Greg Kroah-Hartman
2019-09-04 17:52 ` [PATCH 4.9 04/83] ASoC: dapm: Fix handling of custom_stop_condition on DAPM graph walks Greg Kroah-Hartman
` (85 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Wenwen Wang, Florian Westphal,
Pablo Neira Ayuso, Sasha Levin
[ Upstream commit 15a78ba1844a8e052c1226f930133de4cef4e7ad ]
In compat_do_replace(), a temporary buffer is allocated through vmalloc()
to hold entries copied from the user space. The buffer address is firstly
saved to 'newinfo->entries', and later on assigned to 'entries_tmp'. Then
the entries in this temporary buffer is copied to the internal kernel
structure through compat_copy_entries(). If this copy process fails,
compat_do_replace() should be terminated. However, the allocated temporary
buffer is not freed on this path, leading to a memory leak.
To fix the bug, free the buffer before returning from compat_do_replace().
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Reviewed-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bridge/netfilter/ebtables.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 142ccaae9c7b6..4a47918b504f8 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -2288,8 +2288,10 @@ static int compat_do_replace(struct net *net, void __user *user,
state.buf_kern_len = size64;
ret = compat_copy_entries(entries_tmp, tmp.entries_size, &state);
- if (WARN_ON(ret < 0))
+ if (WARN_ON(ret < 0)) {
+ vfree(entries_tmp);
goto out_unlock;
+ }
vfree(entries_tmp);
tmp.entries_size = size64;
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 04/83] ASoC: dapm: Fix handling of custom_stop_condition on DAPM graph walks
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2019-09-04 17:52 ` [PATCH 4.9 03/83] netfilter: ebtables: fix a memory leak bug in compat Greg Kroah-Hartman
@ 2019-09-04 17:52 ` Greg Kroah-Hartman
2019-09-04 17:52 ` [PATCH 4.9 05/83] bonding: Force slave speed check after link state recovery for 802.3ad Greg Kroah-Hartman
` (84 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Charles Keepax, Mark Brown, Sasha Levin
[ Upstream commit 8dd26dff00c0636b1d8621acaeef3f6f3a39dd77 ]
DPCM uses snd_soc_dapm_dai_get_connected_widgets to build a
list of the widgets connected to a specific front end DAI so it
can search through this list for available back end DAIs. The
custom_stop_condition was added to is_connected_ep to facilitate this
list not containing more widgets than is necessary. Doing so both
speeds up the DPCM handling as less widgets need to be searched and
avoids issues with CODEC to CODEC links as these would be confused
with back end DAIs if they appeared in the list of available widgets.
custom_stop_condition was implemented by aborting the graph walk
when the condition is triggered, however there is an issue with this
approach. Whilst walking the graph is_connected_ep should update the
endpoints cache on each widget, if the walk is aborted the number
of attached end points is unknown for that sub-graph. When the stop
condition triggered, the original patch ignored the triggering widget
and returned zero connected end points; a later patch updated this
to set the triggering widget's cache to 1 and return that. Both of
these approaches result in inaccurate values being stored in various
end point caches as the values propagate back through the graph,
which can result in later issues with widgets powering/not powering
unexpectedly.
As the original goal was to reduce the size of the widget list passed
to the DPCM code, the simplest solution is to limit the functionality
of the custom_stop_condition to the widget list. This means the rest
of the graph will still be processed resulting in correct end point
caches, but only widgets up to the stop condition will be added to the
returned widget list.
Fixes: 6742064aef7f ("ASoC: dapm: support user-defined stop condition in dai_get_connected_widgets")
Fixes: 5fdd022c2026 ("ASoC: dpcm: play nice with CODEC<->CODEC links")
Fixes: 09464974eaa8 ("ASoC: dapm: Fix to return correct path list in is_connected_ep.")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20190718084333.15598-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/soc-dapm.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index ab647f1fe11bd..08bfc91c686f0 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -1104,8 +1104,8 @@ static __always_inline int is_connected_ep(struct snd_soc_dapm_widget *widget,
list_add_tail(&widget->work_list, list);
if (custom_stop_condition && custom_stop_condition(widget, dir)) {
- widget->endpoints[dir] = 1;
- return widget->endpoints[dir];
+ list = NULL;
+ custom_stop_condition = NULL;
}
if ((widget->is_ep & SND_SOC_DAPM_DIR_TO_EP(dir)) && widget->connected) {
@@ -1142,8 +1142,8 @@ static __always_inline int is_connected_ep(struct snd_soc_dapm_widget *widget,
*
* Optionally, can be supplied with a function acting as a stopping condition.
* This function takes the dapm widget currently being examined and the walk
- * direction as an arguments, it should return true if the walk should be
- * stopped and false otherwise.
+ * direction as an arguments, it should return true if widgets from that point
+ * in the graph onwards should not be added to the widget list.
*/
static int is_connected_output_ep(struct snd_soc_dapm_widget *widget,
struct list_head *list,
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 05/83] bonding: Force slave speed check after link state recovery for 802.3ad
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2019-09-04 17:52 ` [PATCH 4.9 04/83] ASoC: dapm: Fix handling of custom_stop_condition on DAPM graph walks Greg Kroah-Hartman
@ 2019-09-04 17:52 ` Greg Kroah-Hartman
2019-09-04 17:52 ` [PATCH 4.9 06/83] can: dev: call netif_carrier_off() in register_candev() Greg Kroah-Hartman
` (83 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jarod Wilson, Jay Vosburgh,
Veaceslav Falico, Andy Gospodarek, Thomas Falcon,
David S. Miller, Sasha Levin
[ Upstream commit 12185dfe44360f814ac4ead9d22ad2af7511b2e9 ]
The following scenario was encountered during testing of logical
partition mobility on pseries partitions with bonded ibmvnic
adapters in LACP mode.
1. Driver receives a signal that the device has been
swapped, and it needs to reset to initialize the new
device.
2. Driver reports loss of carrier and begins initialization.
3. Bonding driver receives NETDEV_CHANGE notifier and checks
the slave's current speed and duplex settings. Because these
are unknown at the time, the bond sets its link state to
BOND_LINK_FAIL and handles the speed update, clearing
AD_PORT_LACP_ENABLE.
4. Driver finishes recovery and reports that the carrier is on.
5. Bond receives a new notification and checks the speed again.
The speeds are valid but miimon has not altered the link
state yet. AD_PORT_LACP_ENABLE remains off.
Because the slave's link state is still BOND_LINK_FAIL,
no further port checks are made when it recovers. Though
the slave devices are operational and have valid speed
and duplex settings, the bond will not send LACPDU's. The
simplest fix I can see is to force another speed check
in bond_miimon_commit. This way the bond will update
AD_PORT_LACP_ENABLE if needed when transitioning from
BOND_LINK_FAIL to BOND_LINK_UP.
CC: Jarod Wilson <jarod@redhat.com>
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Veaceslav Falico <vfalico@gmail.com>
CC: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/bonding/bond_main.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index d338c319b30e2..8820fb1aec5b4 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2131,6 +2131,15 @@ static void bond_miimon_commit(struct bonding *bond)
bond_for_each_slave(bond, slave, iter) {
switch (slave->new_link) {
case BOND_LINK_NOCHANGE:
+ /* For 802.3ad mode, check current slave speed and
+ * duplex again in case its port was disabled after
+ * invalid speed/duplex reporting but recovered before
+ * link monitoring could make a decision on the actual
+ * link status
+ */
+ if (BOND_MODE(bond) == BOND_MODE_8023AD &&
+ slave->link == BOND_LINK_UP)
+ bond_3ad_adapter_speed_duplex_changed(slave);
continue;
case BOND_LINK_UP:
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 06/83] can: dev: call netif_carrier_off() in register_candev()
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2019-09-04 17:52 ` [PATCH 4.9 05/83] bonding: Force slave speed check after link state recovery for 802.3ad Greg Kroah-Hartman
@ 2019-09-04 17:52 ` Greg Kroah-Hartman
2019-09-04 17:52 ` [PATCH 4.9 07/83] ASoC: Fail card instantiation if DAI format setup fails Greg Kroah-Hartman
` (82 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rasmus Villemoes, Willem de Bruijn,
Marc Kleine-Budde, Sasha Levin
[ Upstream commit c63845609c4700488e5eacd6ab4d06d5d420e5ef ]
CONFIG_CAN_LEDS is deprecated. When trying to use the generic netdev
trigger as suggested, there's a small inconsistency with the link
property: The LED is on initially, stays on when the device is brought
up, and then turns off (as expected) when the device is brought down.
Make sure the LED always reflects the state of the CAN device.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/can/dev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 214a48703a4e4..ffc5467a1ec2b 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -1095,6 +1095,8 @@ static struct rtnl_link_ops can_link_ops __read_mostly = {
int register_candev(struct net_device *dev)
{
dev->rtnl_link_ops = &can_link_ops;
+ netif_carrier_off(dev);
+
return register_netdev(dev);
}
EXPORT_SYMBOL_GPL(register_candev);
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 07/83] ASoC: Fail card instantiation if DAI format setup fails
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2019-09-04 17:52 ` [PATCH 4.9 06/83] can: dev: call netif_carrier_off() in register_candev() Greg Kroah-Hartman
@ 2019-09-04 17:52 ` Greg Kroah-Hartman
2019-09-04 18:10 ` Mark Brown
2019-09-04 17:53 ` [PATCH 4.9 08/83] st21nfca_connectivity_event_received: null check the allocation Greg Kroah-Hartman
` (81 subsequent siblings)
88 siblings, 1 reply; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ricard Wanderlof, Mark Brown, Sasha Levin
[ Upstream commit 40aa5383e393d72f6aa3943a4e7b1aae25a1e43b ]
If the DAI format setup fails, there is no valid communication format
between CPU and CODEC, so fail card instantiation, rather than continue
with a card that will most likely not function properly.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Link: https://lore.kernel.org/r/alpine.DEB.2.20.1907241132350.6338@lnxricardw1.se.axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/soc-core.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 168559b5e9f32..d4fb45710eec1 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1632,8 +1632,11 @@ static int soc_probe_link_dais(struct snd_soc_card *card,
}
}
- if (dai_link->dai_fmt)
- snd_soc_runtime_set_dai_fmt(rtd, dai_link->dai_fmt);
+ if (dai_link->dai_fmt) {
+ ret = snd_soc_runtime_set_dai_fmt(rtd, dai_link->dai_fmt);
+ if (ret)
+ return ret;
+ }
ret = soc_post_component_init(rtd, dai_link->name);
if (ret)
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* Re: [PATCH 4.9 07/83] ASoC: Fail card instantiation if DAI format setup fails
2019-09-04 17:52 ` [PATCH 4.9 07/83] ASoC: Fail card instantiation if DAI format setup fails Greg Kroah-Hartman
@ 2019-09-04 18:10 ` Mark Brown
2019-09-04 18:35 ` Greg Kroah-Hartman
0 siblings, 1 reply; 94+ messages in thread
From: Mark Brown @ 2019-09-04 18:10 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, stable, Ricard Wanderlof, Sasha Levin
[-- Attachment #1: Type: text/plain, Size: 577 bytes --]
On Wed, Sep 04, 2019 at 07:52:59PM +0200, Greg Kroah-Hartman wrote:
> [ Upstream commit 40aa5383e393d72f6aa3943a4e7b1aae25a1e43b ]
>
> If the DAI format setup fails, there is no valid communication format
> between CPU and CODEC, so fail card instantiation, rather than continue
> with a card that will most likely not function properly.
I nacked this patch when Sasha posted it - it only improves diagnostics
and might make systems that worked by accident break since it turns
things into a hard failure, it won't make anything that didn't work
previously work.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 4.9 07/83] ASoC: Fail card instantiation if DAI format setup fails
2019-09-04 18:10 ` Mark Brown
@ 2019-09-04 18:35 ` Greg Kroah-Hartman
2019-09-04 19:05 ` Mark Brown
0 siblings, 1 reply; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 18:35 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-kernel, stable, Ricard Wanderlof, Sasha Levin
On Wed, Sep 04, 2019 at 07:10:27PM +0100, Mark Brown wrote:
> On Wed, Sep 04, 2019 at 07:52:59PM +0200, Greg Kroah-Hartman wrote:
> > [ Upstream commit 40aa5383e393d72f6aa3943a4e7b1aae25a1e43b ]
> >
> > If the DAI format setup fails, there is no valid communication format
> > between CPU and CODEC, so fail card instantiation, rather than continue
> > with a card that will most likely not function properly.
>
> I nacked this patch when Sasha posted it - it only improves diagnostics
> and might make systems that worked by accident break since it turns
> things into a hard failure, it won't make anything that didn't work
> previously work.
This is already in the 4.14.141, 4.19.69, and 5.2.11 releases, have you
heard any problems there?
I'll be glad to drop this from the 4.9.y and 4.4.y queues, now if you
wish, but just want you to know it's already out there in some releases.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 4.9 07/83] ASoC: Fail card instantiation if DAI format setup fails
2019-09-04 18:35 ` Greg Kroah-Hartman
@ 2019-09-04 19:05 ` Mark Brown
2019-09-05 18:56 ` Greg Kroah-Hartman
0 siblings, 1 reply; 94+ messages in thread
From: Mark Brown @ 2019-09-04 19:05 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, stable, Ricard Wanderlof, Sasha Levin
[-- Attachment #1: Type: text/plain, Size: 876 bytes --]
On Wed, Sep 04, 2019 at 08:35:27PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Sep 04, 2019 at 07:10:27PM +0100, Mark Brown wrote:
> > I nacked this patch when Sasha posted it - it only improves diagnostics
> > and might make systems that worked by accident break since it turns
> > things into a hard failure, it won't make anything that didn't work
> > previously work.
> This is already in the 4.14.141, 4.19.69, and 5.2.11 releases, have you
> heard any problems there?
Ugh, how did that happen? I've not heard any reports but I'd be a lot
more comfortable if this was reverted, these releases haven't been out
that long and the users who'd be affected are mostly doing embedded
stuff.
> I'll be glad to drop this from the 4.9.y and 4.4.y queues, now if you
> wish, but just want you to know it's already out there in some releases.
Yes, please.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 4.9 07/83] ASoC: Fail card instantiation if DAI format setup fails
2019-09-04 19:05 ` Mark Brown
@ 2019-09-05 18:56 ` Greg Kroah-Hartman
0 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-05 18:56 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-kernel, stable, Ricard Wanderlof, Sasha Levin
On Wed, Sep 04, 2019 at 08:05:35PM +0100, Mark Brown wrote:
> On Wed, Sep 04, 2019 at 08:35:27PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Sep 04, 2019 at 07:10:27PM +0100, Mark Brown wrote:
>
> > > I nacked this patch when Sasha posted it - it only improves diagnostics
> > > and might make systems that worked by accident break since it turns
> > > things into a hard failure, it won't make anything that didn't work
> > > previously work.
>
> > This is already in the 4.14.141, 4.19.69, and 5.2.11 releases, have you
> > heard any problems there?
>
> Ugh, how did that happen? I've not heard any reports but I'd be a lot
> more comfortable if this was reverted, these releases haven't been out
> that long and the users who'd be affected are mostly doing embedded
> stuff.
>
> > I'll be glad to drop this from the 4.9.y and 4.4.y queues, now if you
> > wish, but just want you to know it's already out there in some releases.
>
> Yes, please.
Now reverted and dropped, sorry about this.
greg k-h
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 4.9 08/83] st21nfca_connectivity_event_received: null check the allocation
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2019-09-04 17:52 ` [PATCH 4.9 07/83] ASoC: Fail card instantiation if DAI format setup fails Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 09/83] st_nci_hci_connectivity_event_received: " Greg Kroah-Hartman
` (80 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Navid Emamdoost, David S. Miller,
Sasha Levin
[ Upstream commit 9891d06836e67324c9e9c4675ed90fc8b8110034 ]
devm_kzalloc may fail and return null. So the null check is needed.
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/nfc/st21nfca/se.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index 3a98563d4a121..eac608a457f03 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -326,6 +326,8 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host,
transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
skb->len - 2, GFP_KERNEL);
+ if (!transaction)
+ return -ENOMEM;
transaction->aid_len = skb->data[1];
memcpy(transaction->aid, &skb->data[2],
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 09/83] st_nci_hci_connectivity_event_received: null check the allocation
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 08/83] st21nfca_connectivity_event_received: null check the allocation Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 10/83] ASoC: ti: davinci-mcasp: Correct slot_width posed constraint Greg Kroah-Hartman
` (79 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Navid Emamdoost, David S. Miller,
Sasha Levin
[ Upstream commit 3008e06fdf0973770370f97d5f1fba3701d8281d ]
devm_kzalloc may fail and return NULL. So the null check is needed.
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/nfc/st-nci/se.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/nfc/st-nci/se.c b/drivers/nfc/st-nci/se.c
index 56f2112e0cd84..85df2e0093109 100644
--- a/drivers/nfc/st-nci/se.c
+++ b/drivers/nfc/st-nci/se.c
@@ -344,6 +344,8 @@ static int st_nci_hci_connectivity_event_received(struct nci_dev *ndev,
transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
skb->len - 2, GFP_KERNEL);
+ if (!transaction)
+ return -ENOMEM;
transaction->aid_len = skb->data[1];
memcpy(transaction->aid, &skb->data[2], transaction->aid_len);
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 10/83] ASoC: ti: davinci-mcasp: Correct slot_width posed constraint
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 09/83] st_nci_hci_connectivity_event_received: " Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 11/83] net: usb: qmi_wwan: Add the BroadMobi BM818 card Greg Kroah-Hartman
` (78 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peter Ujfalusi, Mark Brown, Sasha Levin
[ Upstream commit 1e112c35e3c96db7c8ca6ddaa96574f00c06e7db ]
The slot_width is a property for the bus while the constraint for
SNDRV_PCM_HW_PARAM_SAMPLE_BITS is for the in memory format.
Applying slot_width constraint to sample_bits works most of the time, but
it will blacklist valid formats in some cases.
With slot_width 24 we can support S24_3LE and S24_LE formats as they both
look the same on the bus, but a a 24 constraint on sample_bits would not
allow S24_LE as it is stored in 32bits in memory.
Implement a simple hw_rule function to allow all formats which require less
or equal number of bits on the bus as slot_width (if configured).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20190726064244.3762-2-peter.ujfalusi@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/davinci/davinci-mcasp.c | 43 ++++++++++++++++++++++++-------
1 file changed, 34 insertions(+), 9 deletions(-)
diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c
index 5a0b17ebfc025..624c209c94981 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -1158,6 +1158,28 @@ static int davinci_mcasp_trigger(struct snd_pcm_substream *substream,
return ret;
}
+static int davinci_mcasp_hw_rule_slot_width(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct davinci_mcasp_ruledata *rd = rule->private;
+ struct snd_mask *fmt = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
+ struct snd_mask nfmt;
+ int i, slot_width;
+
+ snd_mask_none(&nfmt);
+ slot_width = rd->mcasp->slot_width;
+
+ for (i = 0; i <= SNDRV_PCM_FORMAT_LAST; i++) {
+ if (snd_mask_test(fmt, i)) {
+ if (snd_pcm_format_width(i) <= slot_width) {
+ snd_mask_set(&nfmt, i);
+ }
+ }
+ }
+
+ return snd_mask_refine(fmt, &nfmt);
+}
+
static const unsigned int davinci_mcasp_dai_rates[] = {
8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000,
88200, 96000, 176400, 192000,
@@ -1251,7 +1273,7 @@ static int davinci_mcasp_startup(struct snd_pcm_substream *substream,
struct davinci_mcasp_ruledata *ruledata =
&mcasp->ruledata[substream->stream];
u32 max_channels = 0;
- int i, dir;
+ int i, dir, ret;
int tdm_slots = mcasp->tdm_slots;
/* Do not allow more then one stream per direction */
@@ -1280,6 +1302,7 @@ static int davinci_mcasp_startup(struct snd_pcm_substream *substream,
max_channels++;
}
ruledata->serializers = max_channels;
+ ruledata->mcasp = mcasp;
max_channels *= tdm_slots;
/*
* If the already active stream has less channels than the calculated
@@ -1305,20 +1328,22 @@ static int davinci_mcasp_startup(struct snd_pcm_substream *substream,
0, SNDRV_PCM_HW_PARAM_CHANNELS,
&mcasp->chconstr[substream->stream]);
- if (mcasp->slot_width)
- snd_pcm_hw_constraint_minmax(substream->runtime,
- SNDRV_PCM_HW_PARAM_SAMPLE_BITS,
- 8, mcasp->slot_width);
+ if (mcasp->slot_width) {
+ /* Only allow formats require <= slot_width bits on the bus */
+ ret = snd_pcm_hw_rule_add(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_FORMAT,
+ davinci_mcasp_hw_rule_slot_width,
+ ruledata,
+ SNDRV_PCM_HW_PARAM_FORMAT, -1);
+ if (ret)
+ return ret;
+ }
/*
* If we rely on implicit BCLK divider setting we should
* set constraints based on what we can provide.
*/
if (mcasp->bclk_master && mcasp->bclk_div == 0 && mcasp->sysclk_freq) {
- int ret;
-
- ruledata->mcasp = mcasp;
-
ret = snd_pcm_hw_rule_add(substream->runtime, 0,
SNDRV_PCM_HW_PARAM_RATE,
davinci_mcasp_hw_rule_rate,
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 11/83] net: usb: qmi_wwan: Add the BroadMobi BM818 card
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 10/83] ASoC: ti: davinci-mcasp: Correct slot_width posed constraint Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 12/83] isdn: mISDN: hfcsusb: Fix possible null-pointer dereferences in start_isoc_chain() Greg Kroah-Hartman
` (77 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bob Ham, Angus Ainslie (Purism),
David S. Miller, Sasha Levin
[ Upstream commit 9a07406b00cdc6ec689dc142540739575c717f3c ]
The BroadMobi BM818 M.2 card uses the QMI protocol
Signed-off-by: Bob Ham <bob.ham@puri.sm>
Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index d51ad140f46d2..05953e14a064e 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -892,6 +892,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x2001, 0x7e35, 4)}, /* D-Link DWM-222 */
{QMI_FIXED_INTF(0x2020, 0x2031, 4)}, /* Olicard 600 */
{QMI_FIXED_INTF(0x2020, 0x2033, 4)}, /* BroadMobi BM806U */
+ {QMI_FIXED_INTF(0x2020, 0x2060, 4)}, /* BroadMobi BM818 */
{QMI_FIXED_INTF(0x0f3d, 0x68a2, 8)}, /* Sierra Wireless MC7700 */
{QMI_FIXED_INTF(0x114f, 0x68a2, 8)}, /* Sierra Wireless MC7750 */
{QMI_FIXED_INTF(0x1199, 0x68a2, 8)}, /* Sierra Wireless MC7710 in QMI mode */
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 12/83] isdn: mISDN: hfcsusb: Fix possible null-pointer dereferences in start_isoc_chain()
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 11/83] net: usb: qmi_wwan: Add the BroadMobi BM818 card Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 13/83] isdn: hfcsusb: Fix mISDN driver crash caused by transfer buffer on the stack Greg Kroah-Hartman
` (76 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jia-Ju Bai, David S. Miller, Sasha Levin
[ Upstream commit a0d57a552b836206ad7705a1060e6e1ce5a38203 ]
In start_isoc_chain(), usb_alloc_urb() on line 1392 may fail
and return NULL. At this time, fifo->iso[i].urb is assigned to NULL.
Then, fifo->iso[i].urb is used at some places, such as:
LINE 1405: fill_isoc_urb(fifo->iso[i].urb, ...)
urb->number_of_packets = num_packets;
urb->transfer_flags = URB_ISO_ASAP;
urb->actual_length = 0;
urb->interval = interval;
LINE 1416: fifo->iso[i].urb->...
LINE 1419: fifo->iso[i].urb->...
Thus, possible null-pointer dereferences may occur.
To fix these bugs, "continue" is added to avoid using fifo->iso[i].urb
when it is NULL.
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/isdn/hardware/mISDN/hfcsusb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c
index c60c7998af173..6f19530ba2a93 100644
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c
+++ b/drivers/isdn/hardware/mISDN/hfcsusb.c
@@ -1402,6 +1402,7 @@ start_isoc_chain(struct usb_fifo *fifo, int num_packets_per_urb,
printk(KERN_DEBUG
"%s: %s: alloc urb for fifo %i failed",
hw->name, __func__, fifo->fifonum);
+ continue;
}
fifo->iso[i].owner_fifo = (struct usb_fifo *) fifo;
fifo->iso[i].indx = i;
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 13/83] isdn: hfcsusb: Fix mISDN driver crash caused by transfer buffer on the stack
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 12/83] isdn: mISDN: hfcsusb: Fix possible null-pointer dereferences in start_isoc_chain() Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 14/83] perf bench numa: Fix cpu0 binding Greg Kroah-Hartman
` (75 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Juliana Rodrigueiro, David S. Miller,
Sasha Levin
[ Upstream commit d8a1de3d5bb881507602bc02e004904828f88711 ]
Since linux 4.9 it is not possible to use buffers on the stack for DMA transfers.
During usb probe the driver crashes with "transfer buffer is on stack" message.
This fix k-allocates a buffer to be used on "read_reg_atomic", which is a macro
that calls "usb_control_msg" under the hood.
Kernel 4.19 backtrace:
usb_hcd_submit_urb+0x3e5/0x900
? sched_clock+0x9/0x10
? log_store+0x203/0x270
? get_random_u32+0x6f/0x90
? cache_alloc_refill+0x784/0x8a0
usb_submit_urb+0x3b4/0x550
usb_start_wait_urb+0x4e/0xd0
usb_control_msg+0xb8/0x120
hfcsusb_probe+0x6bc/0xb40 [hfcsusb]
usb_probe_interface+0xc2/0x260
really_probe+0x176/0x280
driver_probe_device+0x49/0x130
__driver_attach+0xa9/0xb0
? driver_probe_device+0x130/0x130
bus_for_each_dev+0x5a/0x90
driver_attach+0x14/0x20
? driver_probe_device+0x130/0x130
bus_add_driver+0x157/0x1e0
driver_register+0x51/0xe0
usb_register_driver+0x5d/0x120
? 0xf81ed000
hfcsusb_drv_init+0x17/0x1000 [hfcsusb]
do_one_initcall+0x44/0x190
? free_unref_page_commit+0x6a/0xd0
do_init_module+0x46/0x1c0
load_module+0x1dc1/0x2400
sys_init_module+0xed/0x120
do_fast_syscall_32+0x7a/0x200
entry_SYSENTER_32+0x6b/0xbe
Signed-off-by: Juliana Rodrigueiro <juliana.rodrigueiro@intra2net.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/isdn/hardware/mISDN/hfcsusb.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c
index 6f19530ba2a93..726fba452f5f6 100644
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c
+++ b/drivers/isdn/hardware/mISDN/hfcsusb.c
@@ -1701,13 +1701,23 @@ hfcsusb_stop_endpoint(struct hfcsusb *hw, int channel)
static int
setup_hfcsusb(struct hfcsusb *hw)
{
+ void *dmabuf = kmalloc(sizeof(u_char), GFP_KERNEL);
u_char b;
+ int ret;
if (debug & DBG_HFC_CALL_TRACE)
printk(KERN_DEBUG "%s: %s\n", hw->name, __func__);
+ if (!dmabuf)
+ return -ENOMEM;
+
+ ret = read_reg_atomic(hw, HFCUSB_CHIP_ID, dmabuf);
+
+ memcpy(&b, dmabuf, sizeof(u_char));
+ kfree(dmabuf);
+
/* check the chip id */
- if (read_reg_atomic(hw, HFCUSB_CHIP_ID, &b) != 1) {
+ if (ret != 1) {
printk(KERN_DEBUG "%s: %s: cannot read chip id\n",
hw->name, __func__);
return 1;
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 14/83] perf bench numa: Fix cpu0 binding
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 13/83] isdn: hfcsusb: Fix mISDN driver crash caused by transfer buffer on the stack Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 15/83] can: sja1000: force the string buffer NULL-terminated Greg Kroah-Hartman
` (74 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michael Petlan, Jiri Olsa,
Alexander Shishkin, Andi Kleen, Namhyung Kim, Peter Zijlstra,
Satheesh Rajendran, Arnaldo Carvalho de Melo, Sasha Levin
[ Upstream commit 6bbfe4e602691b90ac866712bd4c43c51e546a60 ]
Michael reported an issue with perf bench numa failing with binding to
cpu0 with '-0' option.
# perf bench numa mem -p 3 -t 1 -P 512 -s 100 -zZcm0 --thp 1 -M 1 -ddd
# Running 'numa/mem' benchmark:
# Running main, "perf bench numa numa-mem -p 3 -t 1 -P 512 -s 100 -zZcm0 --thp 1 -M 1 -ddd"
binding to node 0, mask: 0000000000000001 => -1
perf: bench/numa.c:356: bind_to_memnode: Assertion `!(ret)' failed.
Aborted (core dumped)
This happens when the cpu0 is not part of node0, which is the benchmark
assumption and we can see that's not the case for some powerpc servers.
Using correct node for cpu0 binding.
Reported-by: Michael Petlan <mpetlan@redhat.com>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/20190801142642.28004-1-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/perf/bench/numa.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
index e58be7eeced83..7b364f2926d4f 100644
--- a/tools/perf/bench/numa.c
+++ b/tools/perf/bench/numa.c
@@ -373,8 +373,10 @@ static u8 *alloc_data(ssize_t bytes0, int map_flags,
/* Allocate and initialize all memory on CPU#0: */
if (init_cpu0) {
- orig_mask = bind_to_node(0);
- bind_to_memnode(0);
+ int node = numa_node_of_cpu(0);
+
+ orig_mask = bind_to_node(node);
+ bind_to_memnode(node);
}
bytes = bytes0 + HPSIZE;
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 15/83] can: sja1000: force the string buffer NULL-terminated
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 14/83] perf bench numa: Fix cpu0 binding Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 16/83] can: peak_usb: " Greg Kroah-Hartman
` (73 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Wang Xiayang, Marc Kleine-Budde, Sasha Levin
[ Upstream commit cd28aa2e056cd1ea79fc5f24eed0ce868c6cab5c ]
strncpy() does not ensure NULL-termination when the input string size
equals to the destination buffer size IFNAMSIZ. The output string
'name' is passed to dev_info which relies on NULL-termination.
Use strlcpy() instead.
This issue is identified by a Coccinelle script.
Signed-off-by: Wang Xiayang <xywang.sjtu@sjtu.edu.cn>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/can/sja1000/peak_pcmcia.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/sja1000/peak_pcmcia.c b/drivers/net/can/sja1000/peak_pcmcia.c
index dd56133cc4616..fc9f8b01ecae2 100644
--- a/drivers/net/can/sja1000/peak_pcmcia.c
+++ b/drivers/net/can/sja1000/peak_pcmcia.c
@@ -487,7 +487,7 @@ static void pcan_free_channels(struct pcan_pccard *card)
if (!netdev)
continue;
- strncpy(name, netdev->name, IFNAMSIZ);
+ strlcpy(name, netdev->name, IFNAMSIZ);
unregister_sja1000dev(netdev);
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 16/83] can: peak_usb: force the string buffer NULL-terminated
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 15/83] can: sja1000: force the string buffer NULL-terminated Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 17/83] NFSv4: Fix a potential sleep while atomic in nfs4_do_reclaim() Greg Kroah-Hartman
` (72 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Wang Xiayang, Marc Kleine-Budde, Sasha Levin
[ Upstream commit e787f19373b8a5fa24087800ed78314fd17b984a ]
strncpy() does not ensure NULL-termination when the input string size
equals to the destination buffer size IFNAMSIZ. The output string is
passed to dev_info() which relies on the NULL-termination.
Use strlcpy() instead.
This issue is identified by a Coccinelle script.
Signed-off-by: Wang Xiayang <xywang.sjtu@sjtu.edu.cn>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
index 54c2354053ace..ce0a352a5eaab 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
@@ -879,7 +879,7 @@ static void peak_usb_disconnect(struct usb_interface *intf)
dev_prev_siblings = dev->prev_siblings;
dev->state &= ~PCAN_USB_STATE_CONNECTED;
- strncpy(name, netdev->name, IFNAMSIZ);
+ strlcpy(name, netdev->name, IFNAMSIZ);
unregister_netdev(netdev);
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 17/83] NFSv4: Fix a potential sleep while atomic in nfs4_do_reclaim()
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 16/83] can: peak_usb: " Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 18/83] HID: input: fix a4tech horizontal wheel custom usage Greg Kroah-Hartman
` (71 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, John Hubbard, Trond Myklebust, Sasha Levin
[ Upstream commit c77e22834ae9a11891cb613bd9a551be1b94f2bc ]
John Hubbard reports seeing the following stack trace:
nfs4_do_reclaim
rcu_read_lock /* we are now in_atomic() and must not sleep */
nfs4_purge_state_owners
nfs4_free_state_owner
nfs4_destroy_seqid_counter
rpc_destroy_wait_queue
cancel_delayed_work_sync
__cancel_work_timer
__flush_work
start_flush_work
might_sleep:
(kernel/workqueue.c:2975: BUG)
The solution is to separate out the freeing of the state owners
from nfs4_purge_state_owners(), and perform that outside the atomic
context.
Reported-by: John Hubbard <jhubbard@nvidia.com>
Fixes: 0aaaf5c424c7f ("NFS: Cache state owners after files are closed")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/nfs/nfs4_fs.h | 3 ++-
fs/nfs/nfs4client.c | 5 ++++-
fs/nfs/nfs4state.c | 27 ++++++++++++++++++++++-----
3 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/fs/nfs/nfs4_fs.h b/fs/nfs/nfs4_fs.h
index 1452177c822db..c719389381dc4 100644
--- a/fs/nfs/nfs4_fs.h
+++ b/fs/nfs/nfs4_fs.h
@@ -434,7 +434,8 @@ static inline void nfs4_schedule_session_recovery(struct nfs4_session *session,
extern struct nfs4_state_owner *nfs4_get_state_owner(struct nfs_server *, struct rpc_cred *, gfp_t);
extern void nfs4_put_state_owner(struct nfs4_state_owner *);
-extern void nfs4_purge_state_owners(struct nfs_server *);
+extern void nfs4_purge_state_owners(struct nfs_server *, struct list_head *);
+extern void nfs4_free_state_owners(struct list_head *head);
extern struct nfs4_state * nfs4_get_open_state(struct inode *, struct nfs4_state_owner *);
extern void nfs4_put_open_state(struct nfs4_state *);
extern void nfs4_close_state(struct nfs4_state *, fmode_t);
diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
index 43f42cc30a606..1ec6dd4f3e2e4 100644
--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -781,9 +781,12 @@ found:
static void nfs4_destroy_server(struct nfs_server *server)
{
+ LIST_HEAD(freeme);
+
nfs_server_return_all_delegations(server);
unset_pnfs_layoutdriver(server);
- nfs4_purge_state_owners(server);
+ nfs4_purge_state_owners(server, &freeme);
+ nfs4_free_state_owners(&freeme);
}
/*
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index 6f474b0670323..4e63daeef6339 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -611,24 +611,39 @@ void nfs4_put_state_owner(struct nfs4_state_owner *sp)
/**
* nfs4_purge_state_owners - Release all cached state owners
* @server: nfs_server with cached state owners to release
+ * @head: resulting list of state owners
*
* Called at umount time. Remaining state owners will be on
* the LRU with ref count of zero.
+ * Note that the state owners are not freed, but are added
+ * to the list @head, which can later be used as an argument
+ * to nfs4_free_state_owners.
*/
-void nfs4_purge_state_owners(struct nfs_server *server)
+void nfs4_purge_state_owners(struct nfs_server *server, struct list_head *head)
{
struct nfs_client *clp = server->nfs_client;
struct nfs4_state_owner *sp, *tmp;
- LIST_HEAD(doomed);
spin_lock(&clp->cl_lock);
list_for_each_entry_safe(sp, tmp, &server->state_owners_lru, so_lru) {
- list_move(&sp->so_lru, &doomed);
+ list_move(&sp->so_lru, head);
nfs4_remove_state_owner_locked(sp);
}
spin_unlock(&clp->cl_lock);
+}
- list_for_each_entry_safe(sp, tmp, &doomed, so_lru) {
+/**
+ * nfs4_purge_state_owners - Release all cached state owners
+ * @head: resulting list of state owners
+ *
+ * Frees a list of state owners that was generated by
+ * nfs4_purge_state_owners
+ */
+void nfs4_free_state_owners(struct list_head *head)
+{
+ struct nfs4_state_owner *sp, *tmp;
+
+ list_for_each_entry_safe(sp, tmp, head, so_lru) {
list_del(&sp->so_lru);
nfs4_free_state_owner(sp);
}
@@ -1764,12 +1779,13 @@ static int nfs4_do_reclaim(struct nfs_client *clp, const struct nfs4_state_recov
struct nfs4_state_owner *sp;
struct nfs_server *server;
struct rb_node *pos;
+ LIST_HEAD(freeme);
int status = 0;
restart:
rcu_read_lock();
list_for_each_entry_rcu(server, &clp->cl_superblocks, client_link) {
- nfs4_purge_state_owners(server);
+ nfs4_purge_state_owners(server, &freeme);
spin_lock(&clp->cl_lock);
for (pos = rb_first(&server->state_owners);
pos != NULL;
@@ -1798,6 +1814,7 @@ restart:
spin_unlock(&clp->cl_lock);
}
rcu_read_unlock();
+ nfs4_free_state_owners(&freeme);
return 0;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 18/83] HID: input: fix a4tech horizontal wheel custom usage
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 17/83] NFSv4: Fix a potential sleep while atomic in nfs4_do_reclaim() Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 19/83] net: cxgb3_main: Fix a resource leak in a error path in init_one() Greg Kroah-Hartman
` (70 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nicolas Saenz Julienne, Jiri Kosina,
Sasha Levin
[ Upstream commit 1c703b53e5bfb5c2205c30f0fb157ce271fd42fb ]
Some a4tech mice use the 'GenericDesktop.00b8' usage to inform whether
the previous wheel report was horizontal or vertical. Before
c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key") this
usage was being mapped to 'Relative.Misc'. After the patch it's simply
ignored (usage->type == 0 & usage->code == 0). Which ultimately makes
hid-a4tech ignore the WHEEL/HWHEEL selection event, as it has no
usage->type.
We shouldn't rely on a mapping for that usage as it's nonstandard and
doesn't really map to an input event. So we bypass the mapping and make
sure the custom event handling properly handles both reports.
Fixes: c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key")
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-a4tech.c | 30 +++++++++++++++++++++++++++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-a4tech.c b/drivers/hid/hid-a4tech.c
index 9428ea7cdf8a0..c52bd163abb3e 100644
--- a/drivers/hid/hid-a4tech.c
+++ b/drivers/hid/hid-a4tech.c
@@ -26,12 +26,36 @@
#define A4_2WHEEL_MOUSE_HACK_7 0x01
#define A4_2WHEEL_MOUSE_HACK_B8 0x02
+#define A4_WHEEL_ORIENTATION (HID_UP_GENDESK | 0x000000b8)
+
struct a4tech_sc {
unsigned long quirks;
unsigned int hw_wheel;
__s32 delayed_value;
};
+static int a4_input_mapping(struct hid_device *hdev, struct hid_input *hi,
+ struct hid_field *field, struct hid_usage *usage,
+ unsigned long **bit, int *max)
+{
+ struct a4tech_sc *a4 = hid_get_drvdata(hdev);
+
+ if (a4->quirks & A4_2WHEEL_MOUSE_HACK_B8 &&
+ usage->hid == A4_WHEEL_ORIENTATION) {
+ /*
+ * We do not want to have this usage mapped to anything as it's
+ * nonstandard and doesn't really behave like an HID report.
+ * It's only selecting the orientation (vertical/horizontal) of
+ * the previous mouse wheel report. The input_events will be
+ * generated once both reports are recorded in a4_event().
+ */
+ return -1;
+ }
+
+ return 0;
+
+}
+
static int a4_input_mapped(struct hid_device *hdev, struct hid_input *hi,
struct hid_field *field, struct hid_usage *usage,
unsigned long **bit, int *max)
@@ -53,8 +77,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
struct a4tech_sc *a4 = hid_get_drvdata(hdev);
struct input_dev *input;
- if (!(hdev->claimed & HID_CLAIMED_INPUT) || !field->hidinput ||
- !usage->type)
+ if (!(hdev->claimed & HID_CLAIMED_INPUT) || !field->hidinput)
return 0;
input = field->hidinput->input;
@@ -65,7 +88,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
return 1;
}
- if (usage->hid == 0x000100b8) {
+ if (usage->hid == A4_WHEEL_ORIENTATION) {
input_event(input, EV_REL, value ? REL_HWHEEL :
REL_WHEEL, a4->delayed_value);
return 1;
@@ -129,6 +152,7 @@ MODULE_DEVICE_TABLE(hid, a4_devices);
static struct hid_driver a4_driver = {
.name = "a4tech",
.id_table = a4_devices,
+ .input_mapping = a4_input_mapping,
.input_mapped = a4_input_mapped,
.event = a4_event,
.probe = a4_probe,
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 19/83] net: cxgb3_main: Fix a resource leak in a error path in init_one()
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 18/83] HID: input: fix a4tech horizontal wheel custom usage Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 20/83] net: hisilicon: make hip04_tx_reclaim non-reentrant Greg Kroah-Hartman
` (69 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christophe JAILLET, David S. Miller,
Sasha Levin
[ Upstream commit debea2cd3193ac868289e8893c3a719c265b0612 ]
A call to 'kfree_skb()' is missing in the error handling path of
'init_one()'.
This is already present in 'remove_one()' but is missing here.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
index ddd1ec8f7bd0f..d1a2159e40d6b 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
@@ -3263,7 +3263,7 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (!adapter->regs) {
dev_err(&pdev->dev, "cannot map device registers\n");
err = -ENOMEM;
- goto out_free_adapter;
+ goto out_free_adapter_nofail;
}
adapter->pdev = pdev;
@@ -3381,6 +3381,9 @@ out_free_dev:
if (adapter->port[i])
free_netdev(adapter->port[i]);
+out_free_adapter_nofail:
+ kfree_skb(adapter->nofail_skb);
+
out_free_adapter:
kfree(adapter);
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 20/83] net: hisilicon: make hip04_tx_reclaim non-reentrant
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 19/83] net: cxgb3_main: Fix a resource leak in a error path in init_one() Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 21/83] net: hisilicon: fix hip04-xmit never return TX_BUSY Greg Kroah-Hartman
` (68 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jiangfeng Xiao, David S. Miller, Sasha Levin
[ Upstream commit 1a2c070ae805910a853b4a14818481ed2e17c727 ]
If hip04_tx_reclaim is interrupted while it is running
and then __napi_schedule continues to execute
hip04_rx_poll->hip04_tx_reclaim, reentrancy occurs
and oops is generated. So you need to mask the interrupt
during the hip04_tx_reclaim run.
The kernel oops exception stack is as follows:
Unable to handle kernel NULL pointer dereference
at virtual address 00000050
pgd = c0003000
[00000050] *pgd=80000000a04003, *pmd=00000000
Internal error: Oops: 206 [#1] SMP ARM
Modules linked in: hip04_eth mtdblock mtd_blkdevs mtd
ohci_platform ehci_platform ohci_hcd ehci_hcd
vfat fat sd_mod usb_storage scsi_mod usbcore usb_common
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.4.185 #1
Hardware name: Hisilicon A15
task: c0a250e0 task.stack: c0a00000
PC is at hip04_tx_reclaim+0xe0/0x17c [hip04_eth]
LR is at hip04_tx_reclaim+0x30/0x17c [hip04_eth]
pc : [<bf30c3a4>] lr : [<bf30c2f4>] psr: 600e0313
sp : c0a01d88 ip : 00000000 fp : c0601f9c
r10: 00000000 r9 : c3482380 r8 : 00000001
r7 : 00000000 r6 : 000000e1 r5 : c3482000 r4 : 0000000c
r3 : f2209800 r2 : 00000000 r1 : 00000000 r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 32c5387d Table: 03d28c80 DAC: 55555555
Process swapper/0 (pid: 0, stack limit = 0xc0a00190)
Stack: (0xc0a01d88 to 0xc0a02000)
[<bf30c3a4>] (hip04_tx_reclaim [hip04_eth]) from [<bf30d2e0>]
(hip04_rx_poll+0x88/0x368 [hip04_eth])
[<bf30d2e0>] (hip04_rx_poll [hip04_eth]) from [<c04c2d9c>] (net_rx_action+0x114/0x34c)
[<c04c2d9c>] (net_rx_action) from [<c021eed8>] (__do_softirq+0x218/0x318)
[<c021eed8>] (__do_softirq) from [<c021f284>] (irq_exit+0x88/0xac)
[<c021f284>] (irq_exit) from [<c0240090>] (msa_irq_exit+0x11c/0x1d4)
[<c0240090>] (msa_irq_exit) from [<c02677e0>] (__handle_domain_irq+0x110/0x148)
[<c02677e0>] (__handle_domain_irq) from [<c0201588>] (gic_handle_irq+0xd4/0x118)
[<c0201588>] (gic_handle_irq) from [<c0551700>] (__irq_svc+0x40/0x58)
Exception stack(0xc0a01f30 to 0xc0a01f78)
1f20: c0ae8b40 00000000 00000000 00000000
1f40: 00000002 ffffe000 c0601f9c 00000000 ffffffff c0a2257c c0a22440 c0831a38
1f60: c0a01ec4 c0a01f80 c0203714 c0203718 600e0213 ffffffff
[<c0551700>] (__irq_svc) from [<c0203718>] (arch_cpu_idle+0x20/0x3c)
[<c0203718>] (arch_cpu_idle) from [<c025bfd8>] (cpu_startup_entry+0x244/0x29c)
[<c025bfd8>] (cpu_startup_entry) from [<c054b0d8>] (rest_init+0xc8/0x10c)
[<c054b0d8>] (rest_init) from [<c0800c58>] (start_kernel+0x468/0x514)
Code: a40599e5 016086e2 018088e2 7660efe6 (503090e5)
---[ end trace 1db21d6d09c49d74 ]---
Kernel panic - not syncing: Fatal exception in interrupt
CPU3: stopping
CPU: 3 PID: 0 Comm: swapper/3 Tainted: G D O 4.4.185 #1
Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
index b5d18d95d7b99..1fabbbd4544e7 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -497,6 +497,9 @@ static int hip04_rx_poll(struct napi_struct *napi, int budget)
u16 len;
u32 err;
+ /* clean up tx descriptors */
+ tx_remaining = hip04_tx_reclaim(ndev, false);
+
while (cnt && !last) {
buf = priv->rx_buf[priv->rx_head];
skb = build_skb(buf, priv->rx_buf_size);
@@ -557,8 +560,7 @@ refill:
}
napi_complete(napi);
done:
- /* clean up tx descriptors and start a new timer if necessary */
- tx_remaining = hip04_tx_reclaim(ndev, false);
+ /* start a new timer if necessary */
if (rx < budget && tx_remaining)
hip04_start_tx_timer(priv);
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 21/83] net: hisilicon: fix hip04-xmit never return TX_BUSY
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 20/83] net: hisilicon: make hip04_tx_reclaim non-reentrant Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 22/83] net: hisilicon: Fix dma_map_single failed on arm64 Greg Kroah-Hartman
` (67 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jiangfeng Xiao, David S. Miller, Sasha Levin
[ Upstream commit f2243b82785942be519016067ee6c55a063bbfe2 ]
TX_DESC_NUM is 256, in tx_count, the maximum value of
mod(TX_DESC_NUM - 1) is 254, the variable "count" in
the hip04_mac_start_xmit function is never equal to
(TX_DESC_NUM - 1), so hip04_mac_start_xmit never
return NETDEV_TX_BUSY.
tx_count is modified to mod(TX_DESC_NUM) so that
the maximum value of tx_count can reach
(TX_DESC_NUM - 1), then hip04_mac_start_xmit can reurn
NETDEV_TX_BUSY.
Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
index 1fabbbd4544e7..c7e0b246cfdca 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -185,7 +185,7 @@ struct hip04_priv {
static inline unsigned int tx_count(unsigned int head, unsigned int tail)
{
- return (head - tail) % (TX_DESC_NUM - 1);
+ return (head - tail) % TX_DESC_NUM;
}
static void hip04_config_port(struct net_device *ndev, u32 speed, u32 duplex)
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 22/83] net: hisilicon: Fix dma_map_single failed on arm64
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 21/83] net: hisilicon: fix hip04-xmit never return TX_BUSY Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 23/83] libata: add SG safety checks in SFF pio transfers Greg Kroah-Hartman
` (66 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jiangfeng Xiao, David S. Miller, Sasha Levin
[ Upstream commit 96a50c0d907ac8f5c3d6b051031a19eb8a2b53e3 ]
On the arm64 platform, executing "ifconfig eth0 up" will fail,
returning "ifconfig: SIOCSIFFLAGS: Input/output error."
ndev->dev is not initialized, dma_map_single->get_dma_ops->
dummy_dma_ops->__dummy_map_page will return DMA_ERROR_CODE
directly, so when we use dma_map_single, the first parameter
is to use the device of platform_device.
Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
index c7e0b246cfdca..f7882c1fde16d 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -157,6 +157,7 @@ struct hip04_priv {
unsigned int reg_inten;
struct napi_struct napi;
+ struct device *dev;
struct net_device *ndev;
struct tx_desc *tx_desc;
@@ -387,7 +388,7 @@ static int hip04_tx_reclaim(struct net_device *ndev, bool force)
}
if (priv->tx_phys[tx_tail]) {
- dma_unmap_single(&ndev->dev, priv->tx_phys[tx_tail],
+ dma_unmap_single(priv->dev, priv->tx_phys[tx_tail],
priv->tx_skb[tx_tail]->len,
DMA_TO_DEVICE);
priv->tx_phys[tx_tail] = 0;
@@ -437,8 +438,8 @@ static int hip04_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
return NETDEV_TX_BUSY;
}
- phys = dma_map_single(&ndev->dev, skb->data, skb->len, DMA_TO_DEVICE);
- if (dma_mapping_error(&ndev->dev, phys)) {
+ phys = dma_map_single(priv->dev, skb->data, skb->len, DMA_TO_DEVICE);
+ if (dma_mapping_error(priv->dev, phys)) {
dev_kfree_skb(skb);
return NETDEV_TX_OK;
}
@@ -508,7 +509,7 @@ static int hip04_rx_poll(struct napi_struct *napi, int budget)
goto refill;
}
- dma_unmap_single(&ndev->dev, priv->rx_phys[priv->rx_head],
+ dma_unmap_single(priv->dev, priv->rx_phys[priv->rx_head],
RX_BUF_SIZE, DMA_FROM_DEVICE);
priv->rx_phys[priv->rx_head] = 0;
@@ -537,9 +538,9 @@ refill:
buf = netdev_alloc_frag(priv->rx_buf_size);
if (!buf)
goto done;
- phys = dma_map_single(&ndev->dev, buf,
+ phys = dma_map_single(priv->dev, buf,
RX_BUF_SIZE, DMA_FROM_DEVICE);
- if (dma_mapping_error(&ndev->dev, phys))
+ if (dma_mapping_error(priv->dev, phys))
goto done;
priv->rx_buf[priv->rx_head] = buf;
priv->rx_phys[priv->rx_head] = phys;
@@ -642,9 +643,9 @@ static int hip04_mac_open(struct net_device *ndev)
for (i = 0; i < RX_DESC_NUM; i++) {
dma_addr_t phys;
- phys = dma_map_single(&ndev->dev, priv->rx_buf[i],
+ phys = dma_map_single(priv->dev, priv->rx_buf[i],
RX_BUF_SIZE, DMA_FROM_DEVICE);
- if (dma_mapping_error(&ndev->dev, phys))
+ if (dma_mapping_error(priv->dev, phys))
return -EIO;
priv->rx_phys[i] = phys;
@@ -678,7 +679,7 @@ static int hip04_mac_stop(struct net_device *ndev)
for (i = 0; i < RX_DESC_NUM; i++) {
if (priv->rx_phys[i]) {
- dma_unmap_single(&ndev->dev, priv->rx_phys[i],
+ dma_unmap_single(priv->dev, priv->rx_phys[i],
RX_BUF_SIZE, DMA_FROM_DEVICE);
priv->rx_phys[i] = 0;
}
@@ -829,6 +830,7 @@ static int hip04_mac_probe(struct platform_device *pdev)
return -ENOMEM;
priv = netdev_priv(ndev);
+ priv->dev = d;
priv->ndev = ndev;
platform_set_drvdata(pdev, ndev);
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 23/83] libata: add SG safety checks in SFF pio transfers
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (21 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 22/83] net: hisilicon: Fix dma_map_single failed on arm64 Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 24/83] x86/lib/cpu: Address missing prototypes warning Greg Kroah-Hartman
` (65 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kees Cook, Jens Axboe, Sasha Levin
[ Upstream commit 752ead44491e8c91e14d7079625c5916b30921c5 ]
Abort processing of a command if we run out of mapped data in the
SG list. This should never happen, but a previous bug caused it to
be possible. Play it safe and attempt to abort nicely if we don't
have more SG segments left.
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ata/libata-sff.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 8d22acdf90f0b..0e2bc5b9a78c1 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -703,6 +703,10 @@ static void ata_pio_sector(struct ata_queued_cmd *qc)
unsigned int offset;
unsigned char *buf;
+ if (!qc->cursg) {
+ qc->curbytes = qc->nbytes;
+ return;
+ }
if (qc->curbytes == qc->nbytes - qc->sect_size)
ap->hsm_task_state = HSM_ST_LAST;
@@ -742,6 +746,8 @@ static void ata_pio_sector(struct ata_queued_cmd *qc)
if (qc->cursg_ofs == qc->cursg->length) {
qc->cursg = sg_next(qc->cursg);
+ if (!qc->cursg)
+ ap->hsm_task_state = HSM_ST_LAST;
qc->cursg_ofs = 0;
}
}
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 24/83] x86/lib/cpu: Address missing prototypes warning
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 23/83] libata: add SG safety checks in SFF pio transfers Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 25/83] drm/vmwgfx: fix memory leak when too many retries have occurred Greg Kroah-Hartman
` (64 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Valdis Kletnieks, Thomas Gleixner,
Sasha Levin
[ Upstream commit 04f5bda84b0712d6f172556a7e8dca9ded5e73b9 ]
When building with W=1, warnings about missing prototypes are emitted:
CC arch/x86/lib/cpu.o
arch/x86/lib/cpu.c:5:14: warning: no previous prototype for 'x86_family' [-Wmissing-prototypes]
5 | unsigned int x86_family(unsigned int sig)
| ^~~~~~~~~~
arch/x86/lib/cpu.c:18:14: warning: no previous prototype for 'x86_model' [-Wmissing-prototypes]
18 | unsigned int x86_model(unsigned int sig)
| ^~~~~~~~~
arch/x86/lib/cpu.c:33:14: warning: no previous prototype for 'x86_stepping' [-Wmissing-prototypes]
33 | unsigned int x86_stepping(unsigned int sig)
| ^~~~~~~~~~~~
Add the proper include file so the prototypes are there.
Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/42513.1565234837@turing-police
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/lib/cpu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/lib/cpu.c b/arch/x86/lib/cpu.c
index 2dd1fe13a37b3..19f707992db22 100644
--- a/arch/x86/lib/cpu.c
+++ b/arch/x86/lib/cpu.c
@@ -1,5 +1,6 @@
#include <linux/types.h>
#include <linux/export.h>
+#include <asm/cpu.h>
unsigned int x86_family(unsigned int sig)
{
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 25/83] drm/vmwgfx: fix memory leak when too many retries have occurred
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 24/83] x86/lib/cpu: Address missing prototypes warning Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 26/83] perf pmu-events: Fix missing "cpu_clk_unhalted.core" event Greg Kroah-Hartman
` (63 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Colin Ian King, Deepak Rawat,
Thomas Hellstrom, Sasha Levin
[ Upstream commit 6b7c3b86f0b63134b2ab56508921a0853ffa687a ]
Currently when too many retries have occurred there is a memory
leak on the allocation for reply on the error return path. Fix
this by kfree'ing reply before returning.
Addresses-Coverity: ("Resource leak")
Fixes: a9cd9c044aa9 ("drm/vmwgfx: Add a check to handle host message failure")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index e57a0bad7a626..77df50dd6d30d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -300,8 +300,10 @@ static int vmw_recv_msg(struct rpc_channel *channel, void **msg,
break;
}
- if (retries == RETRIES)
+ if (retries == RETRIES) {
+ kfree(reply);
return -EINVAL;
+ }
*msg_len = reply_len;
*msg = reply;
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 26/83] perf pmu-events: Fix missing "cpu_clk_unhalted.core" event
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (24 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 25/83] drm/vmwgfx: fix memory leak when too many retries have occurred Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 27/83] selftests: kvm: Adding config fragments Greg Kroah-Hartman
` (62 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jin Yao, Alexander Shishkin,
Andi Kleen, Jin Yao, Jiri Olsa, Kan Liang, Peter Zijlstra,
Arnaldo Carvalho de Melo, Sasha Levin
[ Upstream commit 8e6e5bea2e34c61291d00cb3f47560341aa84bc3 ]
The events defined in pmu-events JSON are parsed and added into perf
tool. For fixed counters, we handle the encodings between JSON and perf
by using a static array fixed[].
But the fixed[] has missed an important event "cpu_clk_unhalted.core".
For example, on the Tremont platform,
[root@localhost ~]# perf stat -e cpu_clk_unhalted.core -a
event syntax error: 'cpu_clk_unhalted.core'
\___ parser error
With this patch, the event cpu_clk_unhalted.core can be parsed.
[root@localhost perf]# ./perf stat -e cpu_clk_unhalted.core -a -vvv
------------------------------------------------------------
perf_event_attr:
type 4
size 112
config 0x3c
sample_type IDENTIFIER
read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
disabled 1
inherit 1
exclude_guest 1
------------------------------------------------------------
...
Signed-off-by: Jin Yao <yao.jin@linux.intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jin Yao <yao.jin@intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20190729072755.2166-1-yao.jin@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/perf/pmu-events/jevents.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index 41611d7f9873c..016d12af68773 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -315,6 +315,7 @@ static struct fixed {
{ "inst_retired.any_p", "event=0xc0" },
{ "cpu_clk_unhalted.ref", "event=0x0,umask=0x03" },
{ "cpu_clk_unhalted.thread", "event=0x3c" },
+ { "cpu_clk_unhalted.core", "event=0x3c" },
{ "cpu_clk_unhalted.thread_any", "event=0x3c,any=1" },
{ NULL, NULL},
};
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 27/83] selftests: kvm: Adding config fragments
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (25 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 26/83] perf pmu-events: Fix missing "cpu_clk_unhalted.core" event Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 28/83] HID: wacom: correct misreported EKR ring values Greg Kroah-Hartman
` (61 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Naresh Kamboju, Paolo Bonzini, Sasha Levin
[ Upstream commit c096397c78f766db972f923433031f2dec01cae0 ]
selftests kvm test cases need pre-required kernel configs for the test
to get pass.
Signed-off-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/kvm/config | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 tools/testing/selftests/kvm/config
diff --git a/tools/testing/selftests/kvm/config b/tools/testing/selftests/kvm/config
new file mode 100644
index 0000000000000..63ed533f73d6e
--- /dev/null
+++ b/tools/testing/selftests/kvm/config
@@ -0,0 +1,3 @@
+CONFIG_KVM=y
+CONFIG_KVM_INTEL=y
+CONFIG_KVM_AMD=y
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 28/83] HID: wacom: correct misreported EKR ring values
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (26 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 27/83] selftests: kvm: Adding config fragments Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 29/83] HID: wacom: Correct distance scale for 2nd-gen Intuos devices Greg Kroah-Hartman
` (60 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Aaron Armstrong Skomra, Ping Cheng,
Jason Gerecke, Jiri Kosina
From: Aaron Armstrong Skomra <skomra@gmail.com>
commit fcf887e7caaa813eea821d11bf2b7619a37df37a upstream.
The EKR ring claims a range of 0 to 71 but actually reports
values 1 to 72. The ring is used in relative mode so this
change should not affect users.
Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
Fixes: 72b236d60218f ("HID: wacom: Add support for Express Key Remote.")
Cc: <stable@vger.kernel.org> # v4.3+
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/wacom_wac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -819,7 +819,7 @@ static int wacom_remote_irq(struct wacom
input_report_key(input, BTN_BASE2, (data[11] & 0x02));
if (data[12] & 0x80)
- input_report_abs(input, ABS_WHEEL, (data[12] & 0x7f));
+ input_report_abs(input, ABS_WHEEL, (data[12] & 0x7f) - 1);
else
input_report_abs(input, ABS_WHEEL, 0);
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 29/83] HID: wacom: Correct distance scale for 2nd-gen Intuos devices
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (27 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 28/83] HID: wacom: correct misreported EKR ring values Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 30/83] Revert "dm bufio: fix deadlock with loop device" Greg Kroah-Hartman
` (59 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jason Gerecke, Jiri Kosina
From: Jason Gerecke <jason.gerecke@wacom.com>
commit b72fb1dcd2ea9d29417711cb302cef3006fa8d5a upstream.
Distance values reported by 2nd-gen Intuos tablets are on an inverted
scale (0 == far, 63 == near). We need to change them over to a normal
scale before reporting to userspace or else userspace drivers and
applications can get confused.
Ref: https://github.com/linuxwacom/input-wacom/issues/98
Fixes: eda01dab53 ("HID: wacom: Add four new Intuos devices")
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/wacom_wac.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -949,6 +949,8 @@ static int wacom_intuos_general(struct w
y >>= 1;
distance >>= 1;
}
+ if (features->type == INTUOSHT2)
+ distance = features->distance_max - distance;
input_report_abs(input, ABS_X, x);
input_report_abs(input, ABS_Y, y);
input_report_abs(input, ABS_DISTANCE, distance);
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 30/83] Revert "dm bufio: fix deadlock with loop device"
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (28 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 29/83] HID: wacom: Correct distance scale for 2nd-gen Intuos devices Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 31/83] gpiolib: never report open-drain/source lines as input to user-space Greg Kroah-Hartman
` (58 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Mike Snitzer
From: Mikulas Patocka <mpatocka@redhat.com>
commit cf3591ef832915892f2499b7e54b51d4c578b28c upstream.
Revert the commit bd293d071ffe65e645b4d8104f9d8fe15ea13862. The proper
fix has been made available with commit d0a255e795ab ("loop: set
PF_MEMALLOC_NOIO for the worker thread").
Note that the fix offered by commit bd293d071ffe doesn't really prevent
the deadlock from occuring - if we look at the stacktrace reported by
Junxiao Bi, we see that it hangs in bit_wait_io and not on the mutex -
i.e. it has already successfully taken the mutex. Changing the mutex
from mutex_lock to mutex_trylock won't help with deadlocks that happen
afterwards.
PID: 474 TASK: ffff8813e11f4600 CPU: 10 COMMAND: "kswapd0"
#0 [ffff8813dedfb938] __schedule at ffffffff8173f405
#1 [ffff8813dedfb990] schedule at ffffffff8173fa27
#2 [ffff8813dedfb9b0] schedule_timeout at ffffffff81742fec
#3 [ffff8813dedfba60] io_schedule_timeout at ffffffff8173f186
#4 [ffff8813dedfbaa0] bit_wait_io at ffffffff8174034f
#5 [ffff8813dedfbac0] __wait_on_bit at ffffffff8173fec8
#6 [ffff8813dedfbb10] out_of_line_wait_on_bit at ffffffff8173ff81
#7 [ffff8813dedfbb90] __make_buffer_clean at ffffffffa038736f [dm_bufio]
#8 [ffff8813dedfbbb0] __try_evict_buffer at ffffffffa0387bb8 [dm_bufio]
#9 [ffff8813dedfbbd0] dm_bufio_shrink_scan at ffffffffa0387cc3 [dm_bufio]
#10 [ffff8813dedfbc40] shrink_slab at ffffffff811a87ce
#11 [ffff8813dedfbd30] shrink_zone at ffffffff811ad778
#12 [ffff8813dedfbdc0] kswapd at ffffffff811ae92f
#13 [ffff8813dedfbec0] kthread at ffffffff810a8428
#14 [ffff8813dedfbf50] ret_from_fork at ffffffff81745242
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
Fixes: bd293d071ffe ("dm bufio: fix deadlock with loop device")
Depends-on: d0a255e795ab ("loop: set PF_MEMALLOC_NOIO for the worker thread")
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-bufio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -1585,7 +1585,9 @@ dm_bufio_shrink_scan(struct shrinker *sh
unsigned long freed;
c = container_of(shrink, struct dm_bufio_client, shrinker);
- if (!dm_bufio_trylock(c))
+ if (sc->gfp_mask & __GFP_FS)
+ dm_bufio_lock(c);
+ else if (!dm_bufio_trylock(c))
return SHRINK_STOP;
freed = __scan(c, sc->nr_to_scan, sc->gfp_mask);
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 31/83] gpiolib: never report open-drain/source lines as input to user-space
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (29 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 30/83] Revert "dm bufio: fix deadlock with loop device" Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 32/83] userfaultfd_release: always remove uffd flags and clear vm_userfaultfd_ctx Greg Kroah-Hartman
` (57 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bartosz Golaszewski, Linus Walleij
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
commit 2c60e6b5c9241b24b8b523fefd3e44fb85622cda upstream.
If the driver doesn't support open-drain/source config options, we
emulate this behavior when setting the direction by calling
gpiod_direction_input() if the default value is 0 (open-source) or
1 (open-drain), thus not actively driving the line in those cases.
This however clears the FLAG_IS_OUT bit for the GPIO line descriptor
and makes the LINEINFO ioctl() incorrectly report this line's mode as
'input' to user-space.
This commit modifies the ioctl() to always set the GPIOLINE_FLAG_IS_OUT
bit in the lineinfo structure's flags field. Since it's impossible to
use the input mode and open-drain/source options at the same time, we
can be sure the reported information will be correct.
Fixes: 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20190806114151.17652-1-brgl@bgdev.pl
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpio/gpiolib.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -953,9 +953,11 @@ static long gpio_ioctl(struct file *filp
if (test_bit(FLAG_ACTIVE_LOW, &desc->flags))
lineinfo.flags |= GPIOLINE_FLAG_ACTIVE_LOW;
if (test_bit(FLAG_OPEN_DRAIN, &desc->flags))
- lineinfo.flags |= GPIOLINE_FLAG_OPEN_DRAIN;
+ lineinfo.flags |= (GPIOLINE_FLAG_OPEN_DRAIN |
+ GPIOLINE_FLAG_IS_OUT);
if (test_bit(FLAG_OPEN_SOURCE, &desc->flags))
- lineinfo.flags |= GPIOLINE_FLAG_OPEN_SOURCE;
+ lineinfo.flags |= (GPIOLINE_FLAG_OPEN_SOURCE |
+ GPIOLINE_FLAG_IS_OUT);
if (copy_to_user(ip, &lineinfo, sizeof(lineinfo)))
return -EFAULT;
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 32/83] userfaultfd_release: always remove uffd flags and clear vm_userfaultfd_ctx
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (30 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 31/83] gpiolib: never report open-drain/source lines as input to user-space Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 33/83] x86/retpoline: Dont clobber RFLAGS during CALL_NOSPEC on i386 Greg Kroah-Hartman
` (56 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Oleg Nesterov, Kefeng Wang,
Andrea Arcangeli, Peter Xu, Mike Rapoport, Jann Horn,
Jason Gunthorpe, Michal Hocko, Tetsuo Handa, Andrew Morton,
Linus Torvalds
From: Oleg Nesterov <oleg@redhat.com>
commit 46d0b24c5ee10a15dfb25e20642f5a5ed59c5003 upstream.
userfaultfd_release() should clear vm_flags/vm_userfaultfd_ctx even if
mm->core_state != NULL.
Otherwise a page fault can see userfaultfd_missing() == T and use an
already freed userfaultfd_ctx.
Link: http://lkml.kernel.org/r/20190820160237.GB4983@redhat.com
Fixes: 04f5866e41fb ("coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping")
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Jann Horn <jannh@google.com>
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: <stable@vger.kernel.org>
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>
---
fs/userfaultfd.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -464,6 +464,7 @@ static int userfaultfd_release(struct in
/* len == 0 means wake all */
struct userfaultfd_wake_range range = { .len = 0, };
unsigned long new_flags;
+ bool still_valid;
ACCESS_ONCE(ctx->released) = true;
@@ -479,8 +480,7 @@ static int userfaultfd_release(struct in
* taking the mmap_sem for writing.
*/
down_write(&mm->mmap_sem);
- if (!mmget_still_valid(mm))
- goto skip_mm;
+ still_valid = mmget_still_valid(mm);
prev = NULL;
for (vma = mm->mmap; vma; vma = vma->vm_next) {
cond_resched();
@@ -491,19 +491,20 @@ static int userfaultfd_release(struct in
continue;
}
new_flags = vma->vm_flags & ~(VM_UFFD_MISSING | VM_UFFD_WP);
- prev = vma_merge(mm, prev, vma->vm_start, vma->vm_end,
- new_flags, vma->anon_vma,
- vma->vm_file, vma->vm_pgoff,
- vma_policy(vma),
- NULL_VM_UFFD_CTX);
- if (prev)
- vma = prev;
- else
- prev = vma;
+ if (still_valid) {
+ prev = vma_merge(mm, prev, vma->vm_start, vma->vm_end,
+ new_flags, vma->anon_vma,
+ vma->vm_file, vma->vm_pgoff,
+ vma_policy(vma),
+ NULL_VM_UFFD_CTX);
+ if (prev)
+ vma = prev;
+ else
+ prev = vma;
+ }
vma->vm_flags = new_flags;
vma->vm_userfaultfd_ctx = NULL_VM_UFFD_CTX;
}
-skip_mm:
up_write(&mm->mmap_sem);
mmput(mm);
wakeup:
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 33/83] x86/retpoline: Dont clobber RFLAGS during CALL_NOSPEC on i386
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (31 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 32/83] userfaultfd_release: always remove uffd flags and clear vm_userfaultfd_ctx Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 34/83] x86/apic: Handle missing global clockevent gracefully Greg Kroah-Hartman
` (55 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sean Christopherson, Thomas Gleixner,
Peter Zijlstra (Intel)
From: Sean Christopherson <sean.j.christopherson@intel.com>
commit b63f20a778c88b6a04458ed6ffc69da953d3a109 upstream.
Use 'lea' instead of 'add' when adjusting %rsp in CALL_NOSPEC so as to
avoid clobbering flags.
KVM's emulator makes indirect calls into a jump table of sorts, where
the destination of the CALL_NOSPEC is a small blob of code that performs
fast emulation by executing the target instruction with fixed operands.
adcb_al_dl:
0x000339f8 <+0>: adc %dl,%al
0x000339fa <+2>: ret
A major motiviation for doing fast emulation is to leverage the CPU to
handle consumption and manipulation of arithmetic flags, i.e. RFLAGS is
both an input and output to the target of CALL_NOSPEC. Clobbering flags
results in all sorts of incorrect emulation, e.g. Jcc instructions often
take the wrong path. Sans the nops...
asm("push %[flags]; popf; " CALL_NOSPEC " ; pushf; pop %[flags]\n"
0x0003595a <+58>: mov 0xc0(%ebx),%eax
0x00035960 <+64>: mov 0x60(%ebx),%edx
0x00035963 <+67>: mov 0x90(%ebx),%ecx
0x00035969 <+73>: push %edi
0x0003596a <+74>: popf
0x0003596b <+75>: call *%esi
0x000359a0 <+128>: pushf
0x000359a1 <+129>: pop %edi
0x000359a2 <+130>: mov %eax,0xc0(%ebx)
0x000359b1 <+145>: mov %edx,0x60(%ebx)
ctxt->eflags = (ctxt->eflags & ~EFLAGS_MASK) | (flags & EFLAGS_MASK);
0x000359a8 <+136>: mov -0x10(%ebp),%eax
0x000359ab <+139>: and $0x8d5,%edi
0x000359b4 <+148>: and $0xfffff72a,%eax
0x000359b9 <+153>: or %eax,%edi
0x000359bd <+157>: mov %edi,0x4(%ebx)
For the most part this has gone unnoticed as emulation of guest code
that can trigger fast emulation is effectively limited to MMIO when
running on modern hardware, and MMIO is rarely, if ever, accessed by
instructions that affect or consume flags.
Breakage is almost instantaneous when running with unrestricted guest
disabled, in which case KVM must emulate all instructions when the guest
has invalid state, e.g. when the guest is in Big Real Mode during early
BIOS.
Fixes: 776b043848fd2 ("x86/retpoline: Add initial retpoline support")
Fixes: 1a29b5b7f347a ("KVM: x86: Make indirect calls in emulator speculation safe")
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190822211122.27579-1-sean.j.christopherson@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/nospec-branch.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -196,7 +196,7 @@
" lfence;\n" \
" jmp 902b;\n" \
" .align 16\n" \
- "903: addl $4, %%esp;\n" \
+ "903: lea 4(%%esp), %%esp;\n" \
" pushl %[thunk_target];\n" \
" ret;\n" \
" .align 16\n" \
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 34/83] x86/apic: Handle missing global clockevent gracefully
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (32 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 33/83] x86/retpoline: Dont clobber RFLAGS during CALL_NOSPEC on i386 Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 35/83] x86/boot: Save fields explicitly, zero out everything else Greg Kroah-Hartman
` (54 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Daniel Drake, Jiri Slaby, Thomas Gleixner
From: Thomas Gleixner <tglx@linutronix.de>
commit f897e60a12f0b9146357780d317879bce2a877dc upstream.
Some newer machines do not advertise legacy timers. The kernel can handle
that situation if the TSC and the CPU frequency are enumerated by CPUID or
MSRs and the CPU supports TSC deadline timer. If the CPU does not support
TSC deadline timer the local APIC timer frequency has to be known as well.
Some Ryzens machines do not advertize legacy timers, but there is no
reliable way to determine the bus frequency which feeds the local APIC
timer when the machine allows overclocking of that frequency.
As there is no legacy timer the local APIC timer calibration crashes due to
a NULL pointer dereference when accessing the not installed global clock
event device.
Switch the calibration loop to a non interrupt based one, which polls
either TSC (if frequency is known) or jiffies. The latter requires a global
clockevent. As the machines which do not have a global clockevent installed
have a known TSC frequency this is a non issue. For older machines where
TSC frequency is not known, there is no known case where the legacy timers
do not exist as that would have been reported long ago.
Reported-by: Daniel Drake <drake@endlessm.com>
Reported-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Daniel Drake <drake@endlessm.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1908091443030.21433@nanos.tec.linutronix.de
Link: http://bugzilla.opensuse.org/show_bug.cgi?id=1142926#c12
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/apic/apic.c | 68 ++++++++++++++++++++++++++++++++++----------
1 file changed, 53 insertions(+), 15 deletions(-)
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -629,7 +629,7 @@ static __initdata unsigned long lapic_ca
static __initdata unsigned long lapic_cal_j1, lapic_cal_j2;
/*
- * Temporary interrupt handler.
+ * Temporary interrupt handler and polled calibration function.
*/
static void __init lapic_cal_handler(struct clock_event_device *dev)
{
@@ -713,7 +713,8 @@ calibrate_by_pmtimer(long deltapm, long
static int __init calibrate_APIC_clock(void)
{
struct clock_event_device *levt = this_cpu_ptr(&lapic_events);
- void (*real_handler)(struct clock_event_device *dev);
+ u64 tsc_perj = 0, tsc_start = 0;
+ unsigned long jif_start;
unsigned long deltaj;
long delta, deltatsc;
int pm_referenced = 0;
@@ -742,29 +743,65 @@ static int __init calibrate_APIC_clock(v
apic_printk(APIC_VERBOSE, "Using local APIC timer interrupts.\n"
"calibrating APIC timer ...\n");
+ /*
+ * There are platforms w/o global clockevent devices. Instead of
+ * making the calibration conditional on that, use a polling based
+ * approach everywhere.
+ */
local_irq_disable();
- /* Replace the global interrupt handler */
- real_handler = global_clock_event->event_handler;
- global_clock_event->event_handler = lapic_cal_handler;
-
/*
* Setup the APIC counter to maximum. There is no way the lapic
* can underflow in the 100ms detection time frame
*/
__setup_APIC_LVTT(0xffffffff, 0, 0);
- /* Let the interrupts run */
+ /*
+ * Methods to terminate the calibration loop:
+ * 1) Global clockevent if available (jiffies)
+ * 2) TSC if available and frequency is known
+ */
+ jif_start = READ_ONCE(jiffies);
+
+ if (tsc_khz) {
+ tsc_start = rdtsc();
+ tsc_perj = div_u64((u64)tsc_khz * 1000, HZ);
+ }
+
+ /*
+ * Enable interrupts so the tick can fire, if a global
+ * clockevent device is available
+ */
local_irq_enable();
- while (lapic_cal_loops <= LAPIC_CAL_LOOPS)
- cpu_relax();
+ while (lapic_cal_loops <= LAPIC_CAL_LOOPS) {
+ /* Wait for a tick to elapse */
+ while (1) {
+ if (tsc_khz) {
+ u64 tsc_now = rdtsc();
+ if ((tsc_now - tsc_start) >= tsc_perj) {
+ tsc_start += tsc_perj;
+ break;
+ }
+ } else {
+ unsigned long jif_now = READ_ONCE(jiffies);
+
+ if (time_after(jif_now, jif_start)) {
+ jif_start = jif_now;
+ break;
+ }
+ }
+ cpu_relax();
+ }
+
+ /* Invoke the calibration routine */
+ local_irq_disable();
+ lapic_cal_handler(NULL);
+ local_irq_enable();
+ }
local_irq_disable();
- /* Restore the real event handler */
- global_clock_event->event_handler = real_handler;
-
/* Build delta t1-t2 as apic timer counts down */
delta = lapic_cal_t1 - lapic_cal_t2;
apic_printk(APIC_VERBOSE, "... lapic delta = %ld\n", delta);
@@ -814,10 +851,11 @@ static int __init calibrate_APIC_clock(v
levt->features &= ~CLOCK_EVT_FEAT_DUMMY;
/*
- * PM timer calibration failed or not turned on
- * so lets try APIC timer based calibration
+ * PM timer calibration failed or not turned on so lets try APIC
+ * timer based calibration, if a global clockevent device is
+ * available.
*/
- if (!pm_referenced) {
+ if (!pm_referenced && global_clock_event) {
apic_printk(APIC_VERBOSE, "... verify APIC timer\n");
/*
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 35/83] x86/boot: Save fields explicitly, zero out everything else
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (33 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 34/83] x86/apic: Handle missing global clockevent gracefully Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 36/83] x86/boot: Fix boot regression caused by bootparam sanitizing Greg Kroah-Hartman
` (53 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thomas Gleixner, H. Peter Anvin,
John Hubbard
From: John Hubbard <jhubbard@nvidia.com>
commit a90118c445cc7f07781de26a9684d4ec58bfcfd1 upstream.
Recent gcc compilers (gcc 9.1) generate warnings about an out of bounds
memset, if the memset goes accross several fields of a struct. This
generated a couple of warnings on x86_64 builds in sanitize_boot_params().
Fix this by explicitly saving the fields in struct boot_params
that are intended to be preserved, and zeroing all the rest.
[ tglx: Tagged for stable as it breaks the warning free build there as well ]
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Suggested-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190731054627.5627-2-jhubbard@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/bootparam_utils.h | 59 +++++++++++++++++++++++++--------
1 file changed, 46 insertions(+), 13 deletions(-)
--- a/arch/x86/include/asm/bootparam_utils.h
+++ b/arch/x86/include/asm/bootparam_utils.h
@@ -17,6 +17,20 @@
* Note: efi_info is commonly left uninitialized, but that field has a
* private magic, so it is better to leave it unchanged.
*/
+
+#define sizeof_mbr(type, member) ({ sizeof(((type *)0)->member); })
+
+#define BOOT_PARAM_PRESERVE(struct_member) \
+ { \
+ .start = offsetof(struct boot_params, struct_member), \
+ .len = sizeof_mbr(struct boot_params, struct_member), \
+ }
+
+struct boot_params_to_save {
+ unsigned int start;
+ unsigned int len;
+};
+
static void sanitize_boot_params(struct boot_params *boot_params)
{
/*
@@ -35,19 +49,38 @@ static void sanitize_boot_params(struct
*/
if (boot_params->sentinel) {
/* fields in boot_params are left uninitialized, clear them */
- memset(&boot_params->ext_ramdisk_image, 0,
- (char *)&boot_params->efi_info -
- (char *)&boot_params->ext_ramdisk_image);
- memset(&boot_params->kbd_status, 0,
- (char *)&boot_params->hdr -
- (char *)&boot_params->kbd_status);
- memset(&boot_params->_pad7[0], 0,
- (char *)&boot_params->edd_mbr_sig_buffer[0] -
- (char *)&boot_params->_pad7[0]);
- memset(&boot_params->_pad8[0], 0,
- (char *)&boot_params->eddbuf[0] -
- (char *)&boot_params->_pad8[0]);
- memset(&boot_params->_pad9[0], 0, sizeof(boot_params->_pad9));
+ static struct boot_params scratch;
+ char *bp_base = (char *)boot_params;
+ char *save_base = (char *)&scratch;
+ int i;
+
+ const struct boot_params_to_save to_save[] = {
+ BOOT_PARAM_PRESERVE(screen_info),
+ BOOT_PARAM_PRESERVE(apm_bios_info),
+ BOOT_PARAM_PRESERVE(tboot_addr),
+ BOOT_PARAM_PRESERVE(ist_info),
+ BOOT_PARAM_PRESERVE(hd0_info),
+ BOOT_PARAM_PRESERVE(hd1_info),
+ BOOT_PARAM_PRESERVE(sys_desc_table),
+ BOOT_PARAM_PRESERVE(olpc_ofw_header),
+ BOOT_PARAM_PRESERVE(efi_info),
+ BOOT_PARAM_PRESERVE(alt_mem_k),
+ BOOT_PARAM_PRESERVE(scratch),
+ BOOT_PARAM_PRESERVE(e820_entries),
+ BOOT_PARAM_PRESERVE(eddbuf_entries),
+ BOOT_PARAM_PRESERVE(edd_mbr_sig_buf_entries),
+ BOOT_PARAM_PRESERVE(edd_mbr_sig_buffer),
+ BOOT_PARAM_PRESERVE(eddbuf),
+ };
+
+ memset(&scratch, 0, sizeof(scratch));
+
+ for (i = 0; i < ARRAY_SIZE(to_save); i++) {
+ memcpy(save_base + to_save[i].start,
+ bp_base + to_save[i].start, to_save[i].len);
+ }
+
+ memcpy(boot_params, save_base, sizeof(*boot_params));
}
}
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 36/83] x86/boot: Fix boot regression caused by bootparam sanitizing
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (34 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 35/83] x86/boot: Save fields explicitly, zero out everything else Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 37/83] dm btree: fix order of block initialization in btree_split_beneath Greg Kroah-Hartman
` (52 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Neil MacLeod, Thomas Gleixner, John Hubbard
From: John Hubbard <jhubbard@nvidia.com>
commit 7846f58fba964af7cb8cf77d4d13c33254725211 upstream.
commit a90118c445cc ("x86/boot: Save fields explicitly, zero out everything
else") had two errors:
* It preserved boot_params.acpi_rsdp_addr, and
* It failed to preserve boot_params.hdr
Therefore, zero out acpi_rsdp_addr, and preserve hdr.
Fixes: a90118c445cc ("x86/boot: Save fields explicitly, zero out everything else")
Reported-by: Neil MacLeod <neil@nmacleod.com>
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Neil MacLeod <neil@nmacleod.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190821192513.20126-1-jhubbard@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/bootparam_utils.h | 1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/include/asm/bootparam_utils.h
+++ b/arch/x86/include/asm/bootparam_utils.h
@@ -70,6 +70,7 @@ static void sanitize_boot_params(struct
BOOT_PARAM_PRESERVE(eddbuf_entries),
BOOT_PARAM_PRESERVE(edd_mbr_sig_buf_entries),
BOOT_PARAM_PRESERVE(edd_mbr_sig_buffer),
+ BOOT_PARAM_PRESERVE(hdr),
BOOT_PARAM_PRESERVE(eddbuf),
};
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 37/83] dm btree: fix order of block initialization in btree_split_beneath
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (35 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 36/83] x86/boot: Fix boot regression caused by bootparam sanitizing Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 38/83] dm space map metadata: fix missing store of apply_bops() return value Greg Kroah-Hartman
` (51 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, ZhangXiaoxu, Mike Snitzer
From: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
commit e4f9d6013820d1eba1432d51dd1c5795759aa77f upstream.
When btree_split_beneath() splits a node to two new children, it will
allocate two blocks: left and right. If right block's allocation
failed, the left block will be unlocked and marked dirty. If this
happened, the left block'ss content is zero, because it wasn't
initialized with the btree struct before the attempot to allocate the
right block. Upon return, when flushing the left block to disk, the
validator will fail when check this block. Then a BUG_ON is raised.
Fix this by completely initializing the left block before allocating and
initializing the right block.
Fixes: 4dcb8b57df359 ("dm btree: fix leak of bufio-backed block in btree_split_beneath error path")
Cc: stable@vger.kernel.org
Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/persistent-data/dm-btree.c | 31 ++++++++++++++++---------------
1 file changed, 16 insertions(+), 15 deletions(-)
--- a/drivers/md/persistent-data/dm-btree.c
+++ b/drivers/md/persistent-data/dm-btree.c
@@ -623,39 +623,40 @@ static int btree_split_beneath(struct sh
new_parent = shadow_current(s);
+ pn = dm_block_data(new_parent);
+ size = le32_to_cpu(pn->header.flags) & INTERNAL_NODE ?
+ sizeof(__le64) : s->info->value_type.size;
+
+ /* create & init the left block */
r = new_block(s->info, &left);
if (r < 0)
return r;
+ ln = dm_block_data(left);
+ nr_left = le32_to_cpu(pn->header.nr_entries) / 2;
+
+ ln->header.flags = pn->header.flags;
+ ln->header.nr_entries = cpu_to_le32(nr_left);
+ ln->header.max_entries = pn->header.max_entries;
+ ln->header.value_size = pn->header.value_size;
+ memcpy(ln->keys, pn->keys, nr_left * sizeof(pn->keys[0]));
+ memcpy(value_ptr(ln, 0), value_ptr(pn, 0), nr_left * size);
+
+ /* create & init the right block */
r = new_block(s->info, &right);
if (r < 0) {
unlock_block(s->info, left);
return r;
}
- pn = dm_block_data(new_parent);
- ln = dm_block_data(left);
rn = dm_block_data(right);
-
- nr_left = le32_to_cpu(pn->header.nr_entries) / 2;
nr_right = le32_to_cpu(pn->header.nr_entries) - nr_left;
- ln->header.flags = pn->header.flags;
- ln->header.nr_entries = cpu_to_le32(nr_left);
- ln->header.max_entries = pn->header.max_entries;
- ln->header.value_size = pn->header.value_size;
-
rn->header.flags = pn->header.flags;
rn->header.nr_entries = cpu_to_le32(nr_right);
rn->header.max_entries = pn->header.max_entries;
rn->header.value_size = pn->header.value_size;
-
- memcpy(ln->keys, pn->keys, nr_left * sizeof(pn->keys[0]));
memcpy(rn->keys, pn->keys + nr_left, nr_right * sizeof(pn->keys[0]));
-
- size = le32_to_cpu(pn->header.flags) & INTERNAL_NODE ?
- sizeof(__le64) : s->info->value_type.size;
- memcpy(value_ptr(ln, 0), value_ptr(pn, 0), nr_left * size);
memcpy(value_ptr(rn, 0), value_ptr(pn, nr_left),
nr_right * size);
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 38/83] dm space map metadata: fix missing store of apply_bops() return value
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (36 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 37/83] dm btree: fix order of block initialization in btree_split_beneath Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 39/83] dm table: fix invalid memory accesses with too high sector number Greg Kroah-Hartman
` (50 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, ZhangXiaoxu, Mike Snitzer
From: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
commit ae148243d3f0816b37477106c05a2ec7d5f32614 upstream.
In commit 6096d91af0b6 ("dm space map metadata: fix occasional leak
of a metadata block on resize"), we refactor the commit logic to a new
function 'apply_bops'. But when that logic was replaced in out() the
return value was not stored. This may lead out() returning a wrong
value to the caller.
Fixes: 6096d91af0b6 ("dm space map metadata: fix occasional leak of a metadata block on resize")
Cc: stable@vger.kernel.org
Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/persistent-data/dm-space-map-metadata.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/md/persistent-data/dm-space-map-metadata.c
+++ b/drivers/md/persistent-data/dm-space-map-metadata.c
@@ -248,7 +248,7 @@ static int out(struct sm_metadata *smm)
}
if (smm->recursion_count == 1)
- apply_bops(smm);
+ r = apply_bops(smm);
smm->recursion_count--;
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 39/83] dm table: fix invalid memory accesses with too high sector number
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (37 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 38/83] dm space map metadata: fix missing store of apply_bops() return value Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 40/83] genirq: Properly pair kobject_del() with kobject_add() Greg Kroah-Hartman
` (49 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Zhang Tao, Mikulas Patocka, Mike Snitzer
From: Mikulas Patocka <mpatocka@redhat.com>
commit 1cfd5d3399e87167b7f9157ef99daa0e959f395d upstream.
If the sector number is too high, dm_table_find_target() should return a
pointer to a zeroed dm_target structure (the caller should test it with
dm_target_is_valid).
However, for some table sizes, the code in dm_table_find_target() that
performs btree lookup will access out of bound memory structures.
Fix this bug by testing the sector number at the beginning of
dm_table_find_target(). Also, add an "inline" keyword to the function
dm_table_get_size() because this is a hot path.
Fixes: 512875bd9661 ("dm: table detect io beyond device")
Cc: stable@vger.kernel.org
Reported-by: Zhang Tao <kontais@zoho.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-table.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -1263,7 +1263,7 @@ void dm_table_event(struct dm_table *t)
}
EXPORT_SYMBOL(dm_table_event);
-sector_t dm_table_get_size(struct dm_table *t)
+inline sector_t dm_table_get_size(struct dm_table *t)
{
return t->num_targets ? (t->highs[t->num_targets - 1] + 1) : 0;
}
@@ -1288,6 +1288,9 @@ struct dm_target *dm_table_find_target(s
unsigned int l, n = 0, k = 0;
sector_t *node;
+ if (unlikely(sector >= dm_table_get_size(t)))
+ return &t->targets[t->num_targets];
+
for (l = 0; l < t->depth; l++) {
n = get_child(n, k);
node = get_node(t, l, n);
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 40/83] genirq: Properly pair kobject_del() with kobject_add()
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (38 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 39/83] dm table: fix invalid memory accesses with too high sector number Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 41/83] mm, page_owner: handle THP splits correctly Greg Kroah-Hartman
` (48 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Michael Kelley, Thomas Gleixner
From: Michael Kelley <mikelley@microsoft.com>
commit d0ff14fdc987303aeeb7de6f1bd72c3749ae2a9b upstream.
If alloc_descs() fails before irq_sysfs_init() has run, free_desc() in the
cleanup path will call kobject_del() even though the kobject has not been
added with kobject_add().
Fix this by making the call to kobject_del() conditional on whether
irq_sysfs_init() has run.
This problem surfaced because commit aa30f47cf666 ("kobject: Add support
for default attribute groups to kobj_type") makes kobject_del() stricter
about pairing with kobject_add(). If the pairing is incorrrect, a WARNING
and backtrace occur in sysfs_remove_group() because there is no parent.
[ tglx: Add a comment to the code and make it work with CONFIG_SYSFS=n ]
Fixes: ecb3f394c5db ("genirq: Expose interrupt information through sysfs")
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/1564703564-4116-1-git-send-email-mikelley@microsoft.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/irq/irqdesc.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -267,6 +267,18 @@ static void irq_sysfs_add(int irq, struc
}
}
+static void irq_sysfs_del(struct irq_desc *desc)
+{
+ /*
+ * If irq_sysfs_init() has not yet been invoked (early boot), then
+ * irq_kobj_base is NULL and the descriptor was never added.
+ * kobject_del() complains about a object with no parent, so make
+ * it conditional.
+ */
+ if (irq_kobj_base)
+ kobject_del(&desc->kobj);
+}
+
static int __init irq_sysfs_init(void)
{
struct irq_desc *desc;
@@ -297,6 +309,7 @@ static struct kobj_type irq_kobj_type =
};
static void irq_sysfs_add(int irq, struct irq_desc *desc) {}
+static void irq_sysfs_del(struct irq_desc *desc) {}
#endif /* CONFIG_SYSFS */
@@ -406,7 +419,7 @@ static void free_desc(unsigned int irq)
* The sysfs entry must be serialized against a concurrent
* irq_sysfs_init() as well.
*/
- kobject_del(&desc->kobj);
+ irq_sysfs_del(desc);
delete_irq_desc(irq);
/*
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 41/83] mm, page_owner: handle THP splits correctly
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (39 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 40/83] genirq: Properly pair kobject_del() with kobject_add() Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 42/83] mm/zsmalloc.c: migration can leave pages in ZS_EMPTY indefinitely Greg Kroah-Hartman
` (47 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kirill A. Shutemov, Vlastimil Babka,
Michal Hocko, Mel Gorman, Matthew Wilcox, Andrew Morton,
Linus Torvalds
From: Vlastimil Babka <vbabka@suse.cz>
commit f7da677bc6e72033f0981b9d58b5c5d409fa641e upstream.
THP splitting path is missing the split_page_owner() call that
split_page() has.
As a result, split THP pages are wrongly reported in the page_owner file
as order-9 pages. Furthermore when the former head page is freed, the
remaining former tail pages are not listed in the page_owner file at
all. This patch fixes that by adding the split_page_owner() call into
__split_huge_page().
Link: http://lkml.kernel.org/r/20190820131828.22684-2-vbabka@suse.cz
Fixes: a9627bc5e34e ("mm/page_owner: introduce split_page_owner and replace manual handling")
Reported-by: Kirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: <stable@vger.kernel.org>
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>
---
mm/huge_memory.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -30,6 +30,7 @@
#include <linux/userfaultfd_k.h>
#include <linux/page_idle.h>
#include <linux/shmem_fs.h>
+#include <linux/page_owner.h>
#include <asm/tlb.h>
#include <asm/pgalloc.h>
@@ -1950,6 +1951,9 @@ static void __split_huge_page(struct pag
}
ClearPageCompound(head);
+
+ split_page_owner(head, HPAGE_PMD_ORDER);
+
/* See comment in __split_huge_page_tail() */
if (PageAnon(head)) {
page_ref_inc(head);
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 42/83] mm/zsmalloc.c: migration can leave pages in ZS_EMPTY indefinitely
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (40 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 41/83] mm, page_owner: handle THP splits correctly Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 43/83] xfs: fix missing ILOCK unlock when xfs_setattr_nonsize fails due to EDQUOT Greg Kroah-Hartman
` (46 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Henry Burns, Sergey Senozhatsky,
Henry Burns, Minchan Kim, Shakeel Butt, Jonathan Adams,
Andrew Morton, Linus Torvalds
From: Henry Burns <henryburns@google.com>
commit 1a87aa03597efa9641e92875b883c94c7f872ccb upstream.
In zs_page_migrate() we call putback_zspage() after we have finished
migrating all pages in this zspage. However, the return value is
ignored. If a zs_free() races in between zs_page_isolate() and
zs_page_migrate(), freeing the last object in the zspage,
putback_zspage() will leave the page in ZS_EMPTY for potentially an
unbounded amount of time.
To fix this, we need to do the same thing as zs_page_putback() does:
schedule free_work to occur.
To avoid duplicated code, move the sequence to a new
putback_zspage_deferred() function which both zs_page_migrate() and
zs_page_putback() call.
Link: http://lkml.kernel.org/r/20190809181751.219326-1-henryburns@google.com
Fixes: 48b4800a1c6a ("zsmalloc: page migration support")
Signed-off-by: Henry Burns <henryburns@google.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Henry Burns <henrywolfeburns@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Jonathan Adams <jwadams@google.com>
Cc: <stable@vger.kernel.org>
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>
---
mm/zsmalloc.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1939,6 +1939,18 @@ static void dec_zspage_isolation(struct
zspage->isolated--;
}
+static void putback_zspage_deferred(struct zs_pool *pool,
+ struct size_class *class,
+ struct zspage *zspage)
+{
+ enum fullness_group fg;
+
+ fg = putback_zspage(class, zspage);
+ if (fg == ZS_EMPTY)
+ schedule_work(&pool->free_work);
+
+}
+
static void replace_sub_page(struct size_class *class, struct zspage *zspage,
struct page *newpage, struct page *oldpage)
{
@@ -2097,7 +2109,7 @@ int zs_page_migrate(struct address_space
* the list if @page is final isolated subpage in the zspage.
*/
if (!is_zspage_isolated(zspage))
- putback_zspage(class, zspage);
+ putback_zspage_deferred(pool, class, zspage);
reset_page(page);
put_page(page);
@@ -2144,14 +2156,13 @@ void zs_page_putback(struct page *page)
spin_lock(&class->lock);
dec_zspage_isolation(zspage);
if (!is_zspage_isolated(zspage)) {
- fg = putback_zspage(class, zspage);
/*
* Due to page_lock, we cannot free zspage immediately
* so let's defer.
*/
- if (fg == ZS_EMPTY)
- schedule_work(&pool->free_work);
+ putback_zspage_deferred(pool, class, zspage);
}
+
spin_unlock(&class->lock);
}
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 43/83] xfs: fix missing ILOCK unlock when xfs_setattr_nonsize fails due to EDQUOT
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (41 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 42/83] mm/zsmalloc.c: migration can leave pages in ZS_EMPTY indefinitely Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 44/83] Revert "perf test 6: Fix missing kvm module load for s390" Greg Kroah-Hartman
` (45 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, benjamin.moody, Darrick J. Wong,
Dave Chinner, Salvatore Bonaccorso
From: Darrick J. Wong <darrick.wong@oracle.com>
commit 1fb254aa983bf190cfd685d40c64a480a9bafaee upstream.
Benjamin Moody reported to Debian that XFS partially wedges when a chgrp
fails on account of being out of disk quota. I ran his reproducer
script:
# adduser dummy
# adduser dummy plugdev
# dd if=/dev/zero bs=1M count=100 of=test.img
# mkfs.xfs test.img
# mount -t xfs -o gquota test.img /mnt
# mkdir -p /mnt/dummy
# chown -c dummy /mnt/dummy
# xfs_quota -xc 'limit -g bsoft=100k bhard=100k plugdev' /mnt
(and then as user dummy)
$ dd if=/dev/urandom bs=1M count=50 of=/mnt/dummy/foo
$ chgrp plugdev /mnt/dummy/foo
and saw:
================================================
WARNING: lock held when returning to user space!
5.3.0-rc5 #rc5 Tainted: G W
------------------------------------------------
chgrp/47006 is leaving the kernel with locks still held!
1 lock held by chgrp/47006:
#0: 000000006664ea2d (&xfs_nondir_ilock_class){++++}, at: xfs_ilock+0xd2/0x290 [xfs]
...which is clearly caused by xfs_setattr_nonsize failing to unlock the
ILOCK after the xfs_qm_vop_chown_reserve call fails. Add the missing
unlock.
Reported-by: benjamin.moody@gmail.com
Fixes: 253f4911f297 ("xfs: better xfs_trans_alloc interface")
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Tested-by: Salvatore Bonaccorso <carnil@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/xfs/xfs_iops.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/xfs/xfs_iops.c
+++ b/fs/xfs/xfs_iops.c
@@ -774,6 +774,7 @@ xfs_setattr_nonsize(
out_cancel:
xfs_trans_cancel(tp);
+ xfs_iunlock(ip, XFS_ILOCK_EXCL);
out_dqrele:
xfs_qm_dqrele(udqp);
xfs_qm_dqrele(gdqp);
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 44/83] Revert "perf test 6: Fix missing kvm module load for s390"
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (42 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 43/83] xfs: fix missing ILOCK unlock when xfs_setattr_nonsize fails due to EDQUOT Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 45/83] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h Greg Kroah-Hartman
` (44 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Sasha Levin
This reverts commit 9a501cdb05348fa8f85db8df5a82f4b8cd11594e.
Which was upstream commit 53fe307dfd309e425b171f6272d64296a54f4dff.
Ben Hutchings reports that this commit depends on new code added in
v4.18, and so is irrelevant on older kernels, and breaks the build.
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/perf/tests/parse-events.c | 27 ---------------------------
1 file changed, 27 deletions(-)
diff --git a/tools/perf/tests/parse-events.c b/tools/perf/tests/parse-events.c
index 9134a0c3e99df..aa9276bfe3e9b 100644
--- a/tools/perf/tests/parse-events.c
+++ b/tools/perf/tests/parse-events.c
@@ -12,32 +12,6 @@
#define PERF_TP_SAMPLE_TYPE (PERF_SAMPLE_RAW | PERF_SAMPLE_TIME | \
PERF_SAMPLE_CPU | PERF_SAMPLE_PERIOD)
-#if defined(__s390x__)
-/* Return true if kvm module is available and loaded. Test this
- * and retun success when trace point kvm_s390_create_vm
- * exists. Otherwise this test always fails.
- */
-static bool kvm_s390_create_vm_valid(void)
-{
- char *eventfile;
- bool rc = false;
-
- eventfile = get_events_file("kvm-s390");
-
- if (eventfile) {
- DIR *mydir = opendir(eventfile);
-
- if (mydir) {
- rc = true;
- closedir(mydir);
- }
- put_events_file(eventfile);
- }
-
- return rc;
-}
-#endif
-
static int test__checkevent_tracepoint(struct perf_evlist *evlist)
{
struct perf_evsel *evsel = perf_evlist__first(evlist);
@@ -1619,7 +1593,6 @@ static struct evlist_test test__events[] = {
{
.name = "kvm-s390:kvm_s390_create_vm",
.check = test__checkevent_tracepoint,
- .valid = kvm_s390_create_vm_valid,
.id = 100,
},
#endif
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 45/83] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (43 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 44/83] Revert "perf test 6: Fix missing kvm module load for s390" Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 46/83] dmaengine: ste_dma40: fix unneeded variable warning Greg Kroah-Hartman
` (43 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tom Lendacky, Borislav Petkov,
Andrew Cooper, Andrew Morton, Chen Yu, H. Peter Anvin,
Ingo Molnar, Jonathan Corbet, Josh Poimboeuf, Juergen Gross,
Kees Cook, linux-doc, linux-pm, Nathan Chancellor, Paolo Bonzini,
Pavel Machek, Rafael J. Wysocki, Thomas Gleixner, x86,
Sasha Levin
[ Upstream commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24 ]
There have been reports of RDRAND issues after resuming from suspend on
some AMD family 15h and family 16h systems. This issue stems from a BIOS
not performing the proper steps during resume to ensure RDRAND continues
to function properly.
RDRAND support is indicated by CPUID Fn00000001_ECX[30]. This bit can be
reset by clearing MSR C001_1004[62]. Any software that checks for RDRAND
support using CPUID, including the kernel, will believe that RDRAND is
not supported.
Update the CPU initialization to clear the RDRAND CPUID bit for any family
15h and 16h processor that supports RDRAND. If it is known that the family
15h or family 16h system does not have an RDRAND resume issue or that the
system will not be placed in suspend, the "rdrand=force" kernel parameter
can be used to stop the clearing of the RDRAND CPUID bit.
Additionally, update the suspend and resume path to save and restore the
MSR C001_1004 value to ensure that the RDRAND CPUID setting remains in
place after resuming from suspend.
Note, that clearing the RDRAND CPUID bit does not prevent a processor
that normally supports the RDRAND instruction from executing it. So any
code that determined the support based on family and model won't #UD.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Chen Yu <yu.c.chen@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Cc: "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: <stable@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "x86@kernel.org" <x86@kernel.org>
Link: https://lkml.kernel.org/r/7543af91666f491547bd86cebb1e17c66824ab9f.1566229943.git.thomas.lendacky@amd.com
[sl: adjust context in docs]
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Documentation/kernel-parameters.txt | 7 +++
arch/x86/include/asm/msr-index.h | 1 +
arch/x86/kernel/cpu/amd.c | 66 ++++++++++++++++++++++
arch/x86/power/cpu.c | 86 ++++++++++++++++++++++++-----
4 files changed, 147 insertions(+), 13 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index f4f0a1b9ba29e..61b73e42f488c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3829,6 +3829,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
Run specified binary instead of /init from the ramdisk,
used for early userspace startup. See initrd.
+ rdrand= [X86]
+ force - Override the decision by the kernel to hide the
+ advertisement of RDRAND support (this affects
+ certain AMD processors because of buggy BIOS
+ support, specifically around the suspend/resume
+ path).
+
reboot= [KNL]
Format (x86 or x86_64):
[w[arm] | c[old] | h[ard] | s[oft] | g[pio]] \
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 38f94d07920d1..86166868db8c1 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -313,6 +313,7 @@
#define MSR_AMD64_PATCH_LEVEL 0x0000008b
#define MSR_AMD64_TSC_RATIO 0xc0000104
#define MSR_AMD64_NB_CFG 0xc001001f
+#define MSR_AMD64_CPUID_FN_1 0xc0011004
#define MSR_AMD64_PATCH_LOADER 0xc0010020
#define MSR_AMD64_OSVW_ID_LENGTH 0xc0010140
#define MSR_AMD64_OSVW_STATUS 0xc0010141
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 52a65f14db069..9428b54fff664 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -746,6 +746,64 @@ static void init_amd_ln(struct cpuinfo_x86 *c)
msr_set_bit(MSR_AMD64_DE_CFG, 31);
}
+static bool rdrand_force;
+
+static int __init rdrand_cmdline(char *str)
+{
+ if (!str)
+ return -EINVAL;
+
+ if (!strcmp(str, "force"))
+ rdrand_force = true;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+early_param("rdrand", rdrand_cmdline);
+
+static void clear_rdrand_cpuid_bit(struct cpuinfo_x86 *c)
+{
+ /*
+ * Saving of the MSR used to hide the RDRAND support during
+ * suspend/resume is done by arch/x86/power/cpu.c, which is
+ * dependent on CONFIG_PM_SLEEP.
+ */
+ if (!IS_ENABLED(CONFIG_PM_SLEEP))
+ return;
+
+ /*
+ * The nordrand option can clear X86_FEATURE_RDRAND, so check for
+ * RDRAND support using the CPUID function directly.
+ */
+ if (!(cpuid_ecx(1) & BIT(30)) || rdrand_force)
+ return;
+
+ msr_clear_bit(MSR_AMD64_CPUID_FN_1, 62);
+
+ /*
+ * Verify that the CPUID change has occurred in case the kernel is
+ * running virtualized and the hypervisor doesn't support the MSR.
+ */
+ if (cpuid_ecx(1) & BIT(30)) {
+ pr_info_once("BIOS may not properly restore RDRAND after suspend, but hypervisor does not support hiding RDRAND via CPUID.\n");
+ return;
+ }
+
+ clear_cpu_cap(c, X86_FEATURE_RDRAND);
+ pr_info_once("BIOS may not properly restore RDRAND after suspend, hiding RDRAND via CPUID. Use rdrand=force to reenable.\n");
+}
+
+static void init_amd_jg(struct cpuinfo_x86 *c)
+{
+ /*
+ * Some BIOS implementations do not restore proper RDRAND support
+ * across suspend and resume. Check on whether to hide the RDRAND
+ * instruction support via CPUID.
+ */
+ clear_rdrand_cpuid_bit(c);
+}
+
static void init_amd_bd(struct cpuinfo_x86 *c)
{
u64 value;
@@ -760,6 +818,13 @@ static void init_amd_bd(struct cpuinfo_x86 *c)
wrmsrl_safe(MSR_F15H_IC_CFG, value);
}
}
+
+ /*
+ * Some BIOS implementations do not restore proper RDRAND support
+ * across suspend and resume. Check on whether to hide the RDRAND
+ * instruction support via CPUID.
+ */
+ clear_rdrand_cpuid_bit(c);
}
static void init_amd_zn(struct cpuinfo_x86 *c)
@@ -804,6 +869,7 @@ static void init_amd(struct cpuinfo_x86 *c)
case 0x10: init_amd_gh(c); break;
case 0x12: init_amd_ln(c); break;
case 0x15: init_amd_bd(c); break;
+ case 0x16: init_amd_jg(c); break;
case 0x17: init_amd_zn(c); break;
}
diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
index 29dc59baf0c21..c8f947a4aaf20 100644
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -13,6 +13,7 @@
#include <linux/smp.h>
#include <linux/perf_event.h>
#include <linux/tboot.h>
+#include <linux/dmi.h>
#include <asm/pgtable.h>
#include <asm/proto.h>
@@ -24,7 +25,7 @@
#include <asm/debugreg.h>
#include <asm/cpu.h>
#include <asm/mmu_context.h>
-#include <linux/dmi.h>
+#include <asm/cpu_device_id.h>
#ifdef CONFIG_X86_32
__visible unsigned long saved_context_ebx;
@@ -391,15 +392,14 @@ static int __init bsp_pm_check_init(void)
core_initcall(bsp_pm_check_init);
-static int msr_init_context(const u32 *msr_id, const int total_num)
+static int msr_build_context(const u32 *msr_id, const int num)
{
- int i = 0;
+ struct saved_msrs *saved_msrs = &saved_context.saved_msrs;
struct saved_msr *msr_array;
+ int total_num;
+ int i, j;
- if (saved_context.saved_msrs.array || saved_context.saved_msrs.num > 0) {
- pr_err("x86/pm: MSR quirk already applied, please check your DMI match table.\n");
- return -EINVAL;
- }
+ total_num = saved_msrs->num + num;
msr_array = kmalloc_array(total_num, sizeof(struct saved_msr), GFP_KERNEL);
if (!msr_array) {
@@ -407,19 +407,30 @@ static int msr_init_context(const u32 *msr_id, const int total_num)
return -ENOMEM;
}
- for (i = 0; i < total_num; i++) {
- msr_array[i].info.msr_no = msr_id[i];
+ if (saved_msrs->array) {
+ /*
+ * Multiple callbacks can invoke this function, so copy any
+ * MSR save requests from previous invocations.
+ */
+ memcpy(msr_array, saved_msrs->array,
+ sizeof(struct saved_msr) * saved_msrs->num);
+
+ kfree(saved_msrs->array);
+ }
+
+ for (i = saved_msrs->num, j = 0; i < total_num; i++, j++) {
+ msr_array[i].info.msr_no = msr_id[j];
msr_array[i].valid = false;
msr_array[i].info.reg.q = 0;
}
- saved_context.saved_msrs.num = total_num;
- saved_context.saved_msrs.array = msr_array;
+ saved_msrs->num = total_num;
+ saved_msrs->array = msr_array;
return 0;
}
/*
- * The following section is a quirk framework for problematic BIOSen:
+ * The following sections are a quirk framework for problematic BIOSen:
* Sometimes MSRs are modified by the BIOSen after suspended to
* RAM, this might cause unexpected behavior after wakeup.
* Thus we save/restore these specified MSRs across suspend/resume
@@ -434,7 +445,7 @@ static int msr_initialize_bdw(const struct dmi_system_id *d)
u32 bdw_msr_id[] = { MSR_IA32_THERM_CONTROL };
pr_info("x86/pm: %s detected, MSR saving is needed during suspending.\n", d->ident);
- return msr_init_context(bdw_msr_id, ARRAY_SIZE(bdw_msr_id));
+ return msr_build_context(bdw_msr_id, ARRAY_SIZE(bdw_msr_id));
}
static struct dmi_system_id msr_save_dmi_table[] = {
@@ -449,9 +460,58 @@ static struct dmi_system_id msr_save_dmi_table[] = {
{}
};
+static int msr_save_cpuid_features(const struct x86_cpu_id *c)
+{
+ u32 cpuid_msr_id[] = {
+ MSR_AMD64_CPUID_FN_1,
+ };
+
+ pr_info("x86/pm: family %#hx cpu detected, MSR saving is needed during suspending.\n",
+ c->family);
+
+ return msr_build_context(cpuid_msr_id, ARRAY_SIZE(cpuid_msr_id));
+}
+
+static const struct x86_cpu_id msr_save_cpu_table[] = {
+ {
+ .vendor = X86_VENDOR_AMD,
+ .family = 0x15,
+ .model = X86_MODEL_ANY,
+ .feature = X86_FEATURE_ANY,
+ .driver_data = (kernel_ulong_t)msr_save_cpuid_features,
+ },
+ {
+ .vendor = X86_VENDOR_AMD,
+ .family = 0x16,
+ .model = X86_MODEL_ANY,
+ .feature = X86_FEATURE_ANY,
+ .driver_data = (kernel_ulong_t)msr_save_cpuid_features,
+ },
+ {}
+};
+
+typedef int (*pm_cpu_match_t)(const struct x86_cpu_id *);
+static int pm_cpu_check(const struct x86_cpu_id *c)
+{
+ const struct x86_cpu_id *m;
+ int ret = 0;
+
+ m = x86_match_cpu(msr_save_cpu_table);
+ if (m) {
+ pm_cpu_match_t fn;
+
+ fn = (pm_cpu_match_t)m->driver_data;
+ ret = fn(m);
+ }
+
+ return ret;
+}
+
static int pm_check_save_msr(void)
{
dmi_check_system(msr_save_dmi_table);
+ pm_cpu_check(msr_save_cpu_table);
+
return 0;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 46/83] dmaengine: ste_dma40: fix unneeded variable warning
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (44 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 45/83] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 47/83] iommu/dma: Handle SG length overflow better Greg Kroah-Hartman
` (42 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Nathan Chancellor,
Linus Walleij, Vinod Koul, Sasha Levin
[ Upstream commit 5d6fb560729a5d5554e23db8d00eb57cd0021083 ]
clang-9 points out that there are two variables that depending on the
configuration may only be used in an ARRAY_SIZE() expression but not
referenced:
drivers/dma/ste_dma40.c:145:12: error: variable 'd40_backup_regs' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static u32 d40_backup_regs[] = {
^
drivers/dma/ste_dma40.c:214:12: error: variable 'd40_backup_regs_chan' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static u32 d40_backup_regs_chan[] = {
Mark these __maybe_unused to shut up the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190712091357.744515-1-arnd@arndb.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/dma/ste_dma40.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 8684d11b29bba..68b41daab3a8f 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -142,7 +142,7 @@ enum d40_events {
* when the DMA hw is powered off.
* TODO: Add save/restore of D40_DREG_GCC on dma40 v3 or later, if that works.
*/
-static u32 d40_backup_regs[] = {
+static __maybe_unused u32 d40_backup_regs[] = {
D40_DREG_LCPA,
D40_DREG_LCLA,
D40_DREG_PRMSE,
@@ -211,7 +211,7 @@ static u32 d40_backup_regs_v4b[] = {
#define BACKUP_REGS_SZ_V4B ARRAY_SIZE(d40_backup_regs_v4b)
-static u32 d40_backup_regs_chan[] = {
+static __maybe_unused u32 d40_backup_regs_chan[] = {
D40_CHAN_REG_SSCFG,
D40_CHAN_REG_SSELT,
D40_CHAN_REG_SSPTR,
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 47/83] iommu/dma: Handle SG length overflow better
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (45 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 46/83] dmaengine: ste_dma40: fix unneeded variable warning Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 48/83] usb: gadget: composite: Clear "suspended" on reset/disconnect Greg Kroah-Hartman
` (41 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nicolin Chen, Robin Murphy,
Joerg Roedel, Sasha Levin
[ Upstream commit ab2cbeb0ed301a9f0460078e91b09f39958212ef ]
Since scatterlist dimensions are all unsigned ints, in the relatively
rare cases where a device's max_segment_size is set to UINT_MAX, then
the "cur_len + s_length <= max_len" check in __finalise_sg() will always
return true. As a result, the corner case of such a device mapping an
excessively large scatterlist which is mergeable to or beyond a total
length of 4GB can lead to overflow and a bogus truncated dma_length in
the resulting segment.
As we already assume that any single segment must be no longer than
max_len to begin with, this can easily be addressed by reshuffling the
comparison.
Fixes: 809eac54cdd6 ("iommu/dma: Implement scatterlist segment merging")
Reported-by: Nicolin Chen <nicoleotsuka@gmail.com>
Tested-by: Nicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/iommu/dma-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 1520e7f02c2f1..89d191b6a0e0f 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -493,7 +493,7 @@ static int __finalise_sg(struct device *dev, struct scatterlist *sg, int nents,
* - and wouldn't make the resulting output segment too long
*/
if (cur_len && !s_iova_off && (dma_addr & seg_mask) &&
- (cur_len + s_length <= max_len)) {
+ (max_len - cur_len >= s_length)) {
/* ...then concatenate it with the previous one */
cur_len += s_length;
} else {
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 48/83] usb: gadget: composite: Clear "suspended" on reset/disconnect
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (46 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 47/83] iommu/dma: Handle SG length overflow better Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 49/83] xen/blkback: fix memory leaks Greg Kroah-Hartman
` (40 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Benjamin Herrenschmidt, Felipe Balbi,
Sasha Levin
[ Upstream commit 602fda17c7356bb7ae98467d93549057481d11dd ]
In some cases, one can get out of suspend with a reset or
a disconnect followed by a reconnect. Previously we would
leave a stale suspended flag set.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/usb/gadget/composite.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 2c022a08f1638..9fa168af847b5 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -2000,6 +2000,7 @@ void composite_disconnect(struct usb_gadget *gadget)
* disconnect callbacks?
*/
spin_lock_irqsave(&cdev->lock, flags);
+ cdev->suspended = 0;
if (cdev->config)
reset_config(cdev);
if (cdev->driver->disconnect)
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 49/83] xen/blkback: fix memory leaks
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (47 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 48/83] usb: gadget: composite: Clear "suspended" on reset/disconnect Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 50/83] i2c: emev2: avoid race when unregistering slave client Greg Kroah-Hartman
` (39 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Roger Pau Monné,
Boris Ostrovsky, Wenwen Wang, Jens Axboe, Sasha Levin
[ Upstream commit ae78ca3cf3d9e9f914bfcd0bc5c389ff18b9c2e0 ]
In read_per_ring_refs(), after 'req' and related memory regions are
allocated, xen_blkif_map() is invoked to map the shared frame, irq, and
etc. However, if this mapping process fails, no cleanup is performed,
leading to memory leaks. To fix this issue, invoke the cleanup before
returning the error.
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/block/xen-blkback/xenbus.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 5dfe6e8af1408..ad736d7de8383 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -967,6 +967,7 @@ static int read_per_ring_refs(struct xen_blkif_ring *ring, const char *dir)
}
blkif->nr_ring_pages = nr_grefs;
+ err = -ENOMEM;
for (i = 0; i < nr_grefs * XEN_BLKIF_REQS_PER_PAGE; i++) {
req = kzalloc(sizeof(*req), GFP_KERNEL);
if (!req)
@@ -989,7 +990,7 @@ static int read_per_ring_refs(struct xen_blkif_ring *ring, const char *dir)
err = xen_blkif_map(ring, ring_ref, nr_grefs, evtchn);
if (err) {
xenbus_dev_fatal(dev, err, "mapping ring-ref port %u", evtchn);
- return err;
+ goto fail;
}
return 0;
@@ -1009,8 +1010,7 @@ fail:
}
kfree(req);
}
- return -ENOMEM;
-
+ return err;
}
static int connect_ring(struct backend_info *be)
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 50/83] i2c: emev2: avoid race when unregistering slave client
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (48 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 49/83] xen/blkback: fix memory leaks Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 51/83] usb: host: fotg2: restart hcd after port reset Greg Kroah-Hartman
` (38 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Krzysztof Adamski, Wolfram Sang,
Wolfram Sang, Sasha Levin
[ Upstream commit d7437fc0d8291181debe032671a289b6bd93f46f ]
After we disabled interrupts, there might still be an active one
running. Sync before clearing the pointer to the slave device.
Fixes: c31d0a00021d ("i2c: emev2: add slave support")
Reported-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/i2c/busses/i2c-emev2.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-emev2.c b/drivers/i2c/busses/i2c-emev2.c
index 96bb4e7490128..0218ba6eb26ab 100644
--- a/drivers/i2c/busses/i2c-emev2.c
+++ b/drivers/i2c/busses/i2c-emev2.c
@@ -72,6 +72,7 @@ struct em_i2c_device {
struct completion msg_done;
struct clk *sclk;
struct i2c_client *slave;
+ int irq;
};
static inline void em_clear_set_bit(struct em_i2c_device *priv, u8 clear, u8 set, u8 reg)
@@ -342,6 +343,12 @@ static int em_i2c_unreg_slave(struct i2c_client *slave)
writeb(0, priv->base + I2C_OFS_SVA0);
+ /*
+ * Wait for interrupt to finish. New slave irqs cannot happen because we
+ * cleared the slave address and, thus, only extension codes will be
+ * detected which do not use the slave ptr.
+ */
+ synchronize_irq(priv->irq);
priv->slave = NULL;
return 0;
@@ -358,7 +365,7 @@ static int em_i2c_probe(struct platform_device *pdev)
{
struct em_i2c_device *priv;
struct resource *r;
- int irq, ret;
+ int ret;
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -391,8 +398,8 @@ static int em_i2c_probe(struct platform_device *pdev)
em_i2c_reset(&priv->adap);
- irq = platform_get_irq(pdev, 0);
- ret = devm_request_irq(&pdev->dev, irq, em_i2c_irq_handler, 0,
+ priv->irq = platform_get_irq(pdev, 0);
+ ret = devm_request_irq(&pdev->dev, priv->irq, em_i2c_irq_handler, 0,
"em_i2c", priv);
if (ret)
goto err_clk;
@@ -402,7 +409,8 @@ static int em_i2c_probe(struct platform_device *pdev)
if (ret)
goto err_clk;
- dev_info(&pdev->dev, "Added i2c controller %d, irq %d\n", priv->adap.nr, irq);
+ dev_info(&pdev->dev, "Added i2c controller %d, irq %d\n", priv->adap.nr,
+ priv->irq);
return 0;
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 51/83] usb: host: fotg2: restart hcd after port reset
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (49 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 50/83] i2c: emev2: avoid race when unregistering slave client Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 52/83] tools: hv: fix KVP and VSS daemons exit code Greg Kroah-Hartman
` (37 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans Ulli Kroll, Linus Walleij, Sasha Levin
[ Upstream commit 777758888ffe59ef754cc39ab2f275dc277732f4 ]
On the Gemini SoC the FOTG2 stalls after port reset
so restart the HCD after each port reset.
Signed-off-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190810150458.817-1-linus.walleij@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/usb/host/fotg210-hcd.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index 66efa9a676877..72853020a5426 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -1653,6 +1653,10 @@ static int fotg210_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
/* see what we found out */
temp = check_reset_complete(fotg210, wIndex, status_reg,
fotg210_readl(fotg210, status_reg));
+
+ /* restart schedule */
+ fotg210->command |= CMD_RUN;
+ fotg210_writel(fotg210, fotg210->command, &fotg210->regs->command);
}
if (!(temp & (PORT_RESUME|PORT_RESET))) {
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 52/83] tools: hv: fix KVP and VSS daemons exit code
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (50 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 51/83] usb: host: fotg2: restart hcd after port reset Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 53/83] watchdog: bcm2835_wdt: Fix module autoload Greg Kroah-Hartman
` (36 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Adrian Vladu, K. Y. Srinivasan,
Haiyang Zhang, Stephen Hemminger, Sasha Levin,
Alessandro Pilotti
[ Upstream commit b0995156071b0ff29a5902964a9dc8cfad6f81c0 ]
HyperV KVP and VSS daemons should exit with 0 when the '--help'
or '-h' flags are used.
Signed-off-by: Adrian Vladu <avladu@cloudbasesolutions.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Alessandro Pilotti <apilotti@cloudbasesolutions.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/hv/hv_kvp_daemon.c | 2 ++
tools/hv/hv_vss_daemon.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 1774800668168..fffc7c4184599 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1379,6 +1379,8 @@ int main(int argc, char *argv[])
daemonize = 0;
break;
case 'h':
+ print_usage(argv);
+ exit(0);
default:
print_usage(argv);
exit(EXIT_FAILURE);
diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index e0829809c8970..bdc1891e0a9a3 100644
--- a/tools/hv/hv_vss_daemon.c
+++ b/tools/hv/hv_vss_daemon.c
@@ -164,6 +164,8 @@ int main(int argc, char *argv[])
daemonize = 0;
break;
case 'h':
+ print_usage(argv);
+ exit(0);
default:
print_usage(argv);
exit(EXIT_FAILURE);
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 53/83] watchdog: bcm2835_wdt: Fix module autoload
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (51 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 52/83] tools: hv: fix KVP and VSS daemons exit code Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 54/83] scsi: ufs: Fix RX_TERMINATION_FORCE_ENABLE define value Greg Kroah-Hartman
` (35 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stefan Wahren, Guenter Roeck,
Wim Van Sebroeck, Sasha Levin
[ Upstream commit 215e06f0d18d5d653d6ea269e4dfc684854d48bf ]
The commit 5e6acc3e678e ("bcm2835-pm: Move bcm2835-watchdog's DT probe
to an MFD.") broke module autoloading on Raspberry Pi. So add a
module alias this fix this.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/watchdog/bcm2835_wdt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
index 4dddd8298a227..3e2e2e6a8328c 100644
--- a/drivers/watchdog/bcm2835_wdt.c
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -240,6 +240,7 @@ module_param(nowayout, bool, 0);
MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+MODULE_ALIAS("platform:bcm2835-wdt");
MODULE_AUTHOR("Lubomir Rintel <lkundrak@v3.sk>");
MODULE_DESCRIPTION("Driver for Broadcom BCM2835 watchdog timer");
MODULE_LICENSE("GPL");
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 54/83] scsi: ufs: Fix RX_TERMINATION_FORCE_ENABLE define value
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (52 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 53/83] watchdog: bcm2835_wdt: Fix module autoload Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 55/83] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue Greg Kroah-Hartman
` (34 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Pedro Sousa, Martin K. Petersen, Sasha Levin
[ Upstream commit ebcb8f8508c5edf428f52525cec74d28edea7bcb ]
Fix RX_TERMINATION_FORCE_ENABLE define value from 0x0089 to 0x00A9
according to MIPI Alliance MPHY specification.
Fixes: e785060ea3a1 ("ufs: definitions for phy interface")
Signed-off-by: Pedro Sousa <sousa@synopsys.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/ufs/unipro.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/unipro.h b/drivers/scsi/ufs/unipro.h
index 23129d7b2678d..c77e365264478 100644
--- a/drivers/scsi/ufs/unipro.h
+++ b/drivers/scsi/ufs/unipro.h
@@ -52,7 +52,7 @@
#define RX_HS_UNTERMINATED_ENABLE 0x00A6
#define RX_ENTER_HIBERN8 0x00A7
#define RX_BYPASS_8B10B_ENABLE 0x00A8
-#define RX_TERMINATION_FORCE_ENABLE 0x0089
+#define RX_TERMINATION_FORCE_ENABLE 0x00A9
#define RX_MIN_ACTIVATETIME_CAPABILITY 0x008F
#define RX_HIBERN8TIME_CAPABILITY 0x0092
#define RX_REFCLKFREQ 0x00EB
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 55/83] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (53 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 54/83] scsi: ufs: Fix RX_TERMINATION_FORCE_ENABLE define value Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 56/83] ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_term Greg Kroah-Hartman
` (33 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tim Froidcoeur, Matthieu Baerts,
Christoph Paasch, Sasha Levin
Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
triggers following stack trace:
[25244.848046] kernel BUG at ./include/linux/skbuff.h:1406!
[25244.859335] RIP: 0010:skb_queue_prev+0x9/0xc
[25244.888167] Call Trace:
[25244.889182] <IRQ>
[25244.890001] tcp_fragment+0x9c/0x2cf
[25244.891295] tcp_write_xmit+0x68f/0x988
[25244.892732] __tcp_push_pending_frames+0x3b/0xa0
[25244.894347] tcp_data_snd_check+0x2a/0xc8
[25244.895775] tcp_rcv_established+0x2a8/0x30d
[25244.897282] tcp_v4_do_rcv+0xb2/0x158
[25244.898666] tcp_v4_rcv+0x692/0x956
[25244.899959] ip_local_deliver_finish+0xeb/0x169
[25244.901547] __netif_receive_skb_core+0x51c/0x582
[25244.903193] ? inet_gro_receive+0x239/0x247
[25244.904756] netif_receive_skb_internal+0xab/0xc6
[25244.906395] napi_gro_receive+0x8a/0xc0
[25244.907760] receive_buf+0x9a1/0x9cd
[25244.909160] ? load_balance+0x17a/0x7b7
[25244.910536] ? vring_unmap_one+0x18/0x61
[25244.911932] ? detach_buf+0x60/0xfa
[25244.913234] virtnet_poll+0x128/0x1e1
[25244.914607] net_rx_action+0x12a/0x2b1
[25244.915953] __do_softirq+0x11c/0x26b
[25244.917269] ? handle_irq_event+0x44/0x56
[25244.918695] irq_exit+0x61/0xa0
[25244.919947] do_IRQ+0x9d/0xbb
[25244.921065] common_interrupt+0x85/0x85
[25244.922479] </IRQ>
tcp_rtx_queue_tail() (called by tcp_fragment()) can call
tcp_write_queue_prev() on the first packet in the queue, which will trigger
the BUG in tcp_write_queue_prev(), because there is no previous packet.
This happens when the retransmit queue is empty, for example in case of a
zero window.
Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()") was not a
simple cherry-pick of the original one from master (b617158dc096)
because there is a specific TCP rtx queue only since v4.15. For more
details, please see the commit message of b617158dc096 ("tcp: be more
careful in tcp_fragment()").
The BUG() is hit due to the specific code added to versions older than
v4.15. The comment in skb_queue_prev() (include/linux/skbuff.h:1406),
just before the BUG_ON() somehow suggests to add a check before using
it, what Tim did.
In master, this code path causing the issue will not be taken because
the implementation of tcp_rtx_queue_tail() is different:
tcp_fragment() → tcp_rtx_queue_tail() → tcp_write_queue_prev() →
skb_queue_prev() → BUG_ON()
Fixes: 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
Signed-off-by: Tim Froidcoeur <tim.froidcoeur@tessares.net>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Reviewed-by: Christoph Paasch <cpaasch@apple.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/net/tcp.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index a474213ca015b..23814d997e867 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1609,6 +1609,10 @@ static inline struct sk_buff *tcp_rtx_queue_tail(const struct sock *sk)
{
struct sk_buff *skb = tcp_send_head(sk);
+ /* empty retransmit queue, for example due to zero window */
+ if (skb == tcp_write_queue_head(sk))
+ return NULL;
+
return skb ? tcp_write_queue_prev(sk, skb) : tcp_write_queue_tail(sk);
}
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 56/83] ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_term
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (54 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 55/83] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 57/83] ALSA: usb-audio: Fix an OOB bug in parse_audio_mixer_unit Greg Kroah-Hartman
` (32 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hui Peng, Mathias Payer, Takashi Iwai
From: Hui Peng <benquike@gmail.com>
commit 19bce474c45be69a284ecee660aa12d8f1e88f18 upstream.
`check_input_term` recursively calls itself with input from
device side (e.g., uac_input_terminal_descriptor.bCSourceID)
as argument (id). In `check_input_term`, if `check_input_term`
is called with the same `id` argument as the caller, it triggers
endless recursive call, resulting kernel space stack overflow.
This patch fixes the bug by adding a bitmap to `struct mixer_build`
to keep track of the checked ids and stop the execution if some id
has been checked (similar to how parse_audio_unit handles unitid
argument).
Reported-by: Hui Peng <benquike@gmail.com>
Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
Signed-off-by: Hui Peng <benquike@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/usb/mixer.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -82,6 +82,7 @@ struct mixer_build {
unsigned char *buffer;
unsigned int buflen;
DECLARE_BITMAP(unitbitmap, MAX_ID_ELEMS);
+ DECLARE_BITMAP(termbitmap, MAX_ID_ELEMS);
struct usb_audio_term oterm;
const struct usbmix_name_map *map;
const struct usbmix_selector_map *selector_map;
@@ -710,15 +711,24 @@ static int get_term_name(struct mixer_bu
* parse the source unit recursively until it reaches to a terminal
* or a branched unit.
*/
-static int check_input_term(struct mixer_build *state, int id,
+static int __check_input_term(struct mixer_build *state, int id,
struct usb_audio_term *term)
{
int err;
void *p1;
+ unsigned char *hdr;
memset(term, 0, sizeof(*term));
- while ((p1 = find_audio_control_unit(state, id)) != NULL) {
- unsigned char *hdr = p1;
+ for (;;) {
+ /* a loop in the terminal chain? */
+ if (test_and_set_bit(id, state->termbitmap))
+ return -EINVAL;
+
+ p1 = find_audio_control_unit(state, id);
+ if (!p1)
+ break;
+
+ hdr = p1;
term->id = id;
switch (hdr[2]) {
case UAC_INPUT_TERMINAL:
@@ -733,7 +743,7 @@ static int check_input_term(struct mixer
/* call recursively to verify that the
* referenced clock entity is valid */
- err = check_input_term(state, d->bCSourceID, term);
+ err = __check_input_term(state, d->bCSourceID, term);
if (err < 0)
return err;
@@ -765,7 +775,7 @@ static int check_input_term(struct mixer
case UAC2_CLOCK_SELECTOR: {
struct uac_selector_unit_descriptor *d = p1;
/* call recursively to retrieve the channel info */
- err = check_input_term(state, d->baSourceID[0], term);
+ err = __check_input_term(state, d->baSourceID[0], term);
if (err < 0)
return err;
term->type = d->bDescriptorSubtype << 16; /* virtual type */
@@ -812,6 +822,15 @@ static int check_input_term(struct mixer
return -ENODEV;
}
+
+static int check_input_term(struct mixer_build *state, int id,
+ struct usb_audio_term *term)
+{
+ memset(term, 0, sizeof(*term));
+ memset(state->termbitmap, 0, sizeof(state->termbitmap));
+ return __check_input_term(state, id, term);
+}
+
/*
* Feature Unit
*/
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 57/83] ALSA: usb-audio: Fix an OOB bug in parse_audio_mixer_unit
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (55 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 56/83] ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_term Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 58/83] tcp: make sure EPOLLOUT wont be missed Greg Kroah-Hartman
` (31 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hui Peng, Mathias Payer, Takashi Iwai
From: Hui Peng <benquike@gmail.com>
commit daac07156b330b18eb5071aec4b3ddca1c377f2c upstream.
The `uac_mixer_unit_descriptor` shown as below is read from the
device side. In `parse_audio_mixer_unit`, `baSourceID` field is
accessed from index 0 to `bNrInPins` - 1, the current implementation
assumes that descriptor is always valid (the length of descriptor
is no shorter than 5 + `bNrInPins`). If a descriptor read from
the device side is invalid, it may trigger out-of-bound memory
access.
```
struct uac_mixer_unit_descriptor {
__u8 bLength;
__u8 bDescriptorType;
__u8 bDescriptorSubtype;
__u8 bUnitID;
__u8 bNrInPins;
__u8 baSourceID[];
}
```
This patch fixes the bug by add a sanity check on the length of
the descriptor.
Reported-by: Hui Peng <benquike@gmail.com>
Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Peng <benquike@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/usb/mixer.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -1713,6 +1713,7 @@ static int parse_audio_mixer_unit(struct
int pin, ich, err;
if (desc->bLength < 11 || !(input_pins = desc->bNrInPins) ||
+ desc->bLength < sizeof(*desc) + desc->bNrInPins ||
!(num_outs = uac_mixer_unit_bNrChannels(desc))) {
usb_audio_err(state->chip,
"invalid MIXER UNIT descriptor %d\n",
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 58/83] tcp: make sure EPOLLOUT wont be missed
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (56 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 57/83] ALSA: usb-audio: Fix an OOB bug in parse_audio_mixer_unit Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 59/83] ALSA: line6: Fix memory leak at line6_init_pcm() error path Greg Kroah-Hartman
` (30 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Dumazet, Jason Baron,
Vladimir Rutsky, Soheil Hassas Yeganeh, Neal Cardwell,
David S. Miller
From: Eric Dumazet <edumazet@google.com>
[ Upstream commit ef8d8ccdc216f797e66cb4a1372f5c4c285ce1e4 ]
As Jason Baron explained in commit 790ba4566c1a ("tcp: set SOCK_NOSPACE
under memory pressure"), it is crucial we properly set SOCK_NOSPACE
when needed.
However, Jason patch had a bug, because the 'nonblocking' status
as far as sk_stream_wait_memory() is concerned is governed
by MSG_DONTWAIT flag passed at sendmsg() time :
long timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT);
So it is very possible that tcp sendmsg() calls sk_stream_wait_memory(),
and that sk_stream_wait_memory() returns -EAGAIN with SOCK_NOSPACE
cleared, if sk->sk_sndtimeo has been set to a small (but not zero)
value.
This patch removes the 'noblock' variable since we must always
set SOCK_NOSPACE if -EAGAIN is returned.
It also renames the do_nonblock label since we might reach this
code path even if we were in blocking mode.
Fixes: 790ba4566c1a ("tcp: set SOCK_NOSPACE under memory pressure")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jason Baron <jbaron@akamai.com>
Reported-by: Vladimir Rutsky <rutsky@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/stream.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
--- a/net/core/stream.c
+++ b/net/core/stream.c
@@ -118,7 +118,6 @@ int sk_stream_wait_memory(struct sock *s
int err = 0;
long vm_wait = 0;
long current_timeo = *timeo_p;
- bool noblock = (*timeo_p ? false : true);
DEFINE_WAIT(wait);
if (sk_stream_memory_free(sk))
@@ -131,11 +130,8 @@ int sk_stream_wait_memory(struct sock *s
if (sk->sk_err || (sk->sk_shutdown & SEND_SHUTDOWN))
goto do_error;
- if (!*timeo_p) {
- if (noblock)
- set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
- goto do_nonblock;
- }
+ if (!*timeo_p)
+ goto do_eagain;
if (signal_pending(current))
goto do_interrupted;
sk_clear_bit(SOCKWQ_ASYNC_NOSPACE, sk);
@@ -167,7 +163,13 @@ out:
do_error:
err = -EPIPE;
goto out;
-do_nonblock:
+do_eagain:
+ /* Make sure that whenever EAGAIN is returned, EPOLLOUT event can
+ * be generated later.
+ * When TCP receives ACK packets that make room, tcp_check_space()
+ * only calls tcp_new_space() if SOCK_NOSPACE is set.
+ */
+ set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
err = -EAGAIN;
goto out;
do_interrupted:
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 59/83] ALSA: line6: Fix memory leak at line6_init_pcm() error path
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (57 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 58/83] tcp: make sure EPOLLOUT wont be missed Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 60/83] ALSA: seq: Fix potential concurrent access to the deleted pool Greg Kroah-Hartman
` (29 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 1bc8d18c75fef3b478dbdfef722aae09e2a9fde7 upstream.
I forgot to release the allocated object at the early error path in
line6_init_pcm(). For addressing it, slightly shuffle the code so
that the PCM destructor (pcm->private_free) is assigned properly
before all error paths.
Fixes: 3450121997ce ("ALSA: line6: Fix write on zero-sized buffer")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/usb/line6/pcm.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
--- a/sound/usb/line6/pcm.c
+++ b/sound/usb/line6/pcm.c
@@ -552,6 +552,15 @@ int line6_init_pcm(struct usb_line6 *lin
line6pcm->volume_monitor = 255;
line6pcm->line6 = line6;
+ spin_lock_init(&line6pcm->out.lock);
+ spin_lock_init(&line6pcm->in.lock);
+ line6pcm->impulse_period = LINE6_IMPULSE_DEFAULT_PERIOD;
+
+ line6->line6pcm = line6pcm;
+
+ pcm->private_data = line6pcm;
+ pcm->private_free = line6_cleanup_pcm;
+
line6pcm->max_packet_size_in =
usb_maxpacket(line6->usbdev,
usb_rcvisocpipe(line6->usbdev, ep_read), 0);
@@ -564,15 +573,6 @@ int line6_init_pcm(struct usb_line6 *lin
return -EINVAL;
}
- spin_lock_init(&line6pcm->out.lock);
- spin_lock_init(&line6pcm->in.lock);
- line6pcm->impulse_period = LINE6_IMPULSE_DEFAULT_PERIOD;
-
- line6->line6pcm = line6pcm;
-
- pcm->private_data = line6pcm;
- pcm->private_free = line6_cleanup_pcm;
-
err = line6_create_audio_out_urbs(line6pcm);
if (err < 0)
return err;
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 60/83] ALSA: seq: Fix potential concurrent access to the deleted pool
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (58 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 59/83] ALSA: line6: Fix memory leak at line6_init_pcm() error path Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 61/83] KVM: x86: Dont update RIP or do single-step on faulting emulation Greg Kroah-Hartman
` (28 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+4a75454b9ca2777f35c7, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 75545304eba6a3d282f923b96a466dc25a81e359 upstream.
The input pool of a client might be deleted via the resize ioctl, the
the access to it should be covered by the proper locks. Currently the
only missing place is the call in snd_seq_ioctl_get_client_pool(), and
this patch papers over it.
Reported-by: syzbot+4a75454b9ca2777f35c7@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/seq/seq_clientmgr.c | 3 +--
sound/core/seq/seq_fifo.c | 17 +++++++++++++++++
sound/core/seq/seq_fifo.h | 2 ++
3 files changed, 20 insertions(+), 2 deletions(-)
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -1822,8 +1822,7 @@ static int snd_seq_ioctl_get_client_pool
if (cptr->type == USER_CLIENT) {
info->input_pool = cptr->data.user.fifo_pool_size;
info->input_free = info->input_pool;
- if (cptr->data.user.fifo)
- info->input_free = snd_seq_unused_cells(cptr->data.user.fifo->pool);
+ info->input_free = snd_seq_fifo_unused_cells(cptr->data.user.fifo);
} else {
info->input_pool = 0;
info->input_free = 0;
--- a/sound/core/seq/seq_fifo.c
+++ b/sound/core/seq/seq_fifo.c
@@ -278,3 +278,20 @@ int snd_seq_fifo_resize(struct snd_seq_f
return 0;
}
+
+/* get the number of unused cells safely */
+int snd_seq_fifo_unused_cells(struct snd_seq_fifo *f)
+{
+ unsigned long flags;
+ int cells;
+
+ if (!f)
+ return 0;
+
+ snd_use_lock_use(&f->use_lock);
+ spin_lock_irqsave(&f->lock, flags);
+ cells = snd_seq_unused_cells(f->pool);
+ spin_unlock_irqrestore(&f->lock, flags);
+ snd_use_lock_free(&f->use_lock);
+ return cells;
+}
--- a/sound/core/seq/seq_fifo.h
+++ b/sound/core/seq/seq_fifo.h
@@ -68,5 +68,7 @@ int snd_seq_fifo_poll_wait(struct snd_se
/* resize pool in fifo */
int snd_seq_fifo_resize(struct snd_seq_fifo *f, int poolsize);
+/* get the number of unused cells safely */
+int snd_seq_fifo_unused_cells(struct snd_seq_fifo *f);
#endif
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 61/83] KVM: x86: Dont update RIP or do single-step on faulting emulation
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (59 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 60/83] ALSA: seq: Fix potential concurrent access to the deleted pool Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 62/83] x86/apic: Do not initialize LDR and DFR for bigsmp Greg Kroah-Hartman
` (27 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nadav Amit, Andy Lutomirski,
Sean Christopherson, Radim Krčmář
From: Sean Christopherson <sean.j.christopherson@intel.com>
commit 75ee23b30dc712d80d2421a9a547e7ab6e379b44 upstream.
Don't advance RIP or inject a single-step #DB if emulation signals a
fault. This logic applies to all state updates that are conditional on
clean retirement of the emulation instruction, e.g. updating RFLAGS was
previously handled by commit 38827dbd3fb85 ("KVM: x86: Do not update
EFLAGS on faulting emulation").
Not advancing RIP is likely a nop, i.e. ctxt->eip isn't updated with
ctxt->_eip until emulation "retires" anyways. Skipping #DB injection
fixes a bug reported by Andy Lutomirski where a #UD on SYSCALL due to
invalid state with EFLAGS.TF=1 would loop indefinitely due to emulation
overwriting the #UD with #DB and thus restarting the bad SYSCALL over
and over.
Cc: Nadav Amit <nadav.amit@gmail.com>
Cc: stable@vger.kernel.org
Reported-by: Andy Lutomirski <luto@kernel.org>
Fixes: 663f4c61b803 ("KVM: x86: handle singlestep during emulation")
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/x86.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5823,12 +5823,13 @@ restart:
unsigned long rflags = kvm_x86_ops->get_rflags(vcpu);
toggle_interruptibility(vcpu, ctxt->interruptibility);
vcpu->arch.emulate_regs_need_sync_to_vcpu = false;
- kvm_rip_write(vcpu, ctxt->eip);
- if (r == EMULATE_DONE && ctxt->tf)
- kvm_vcpu_do_singlestep(vcpu, &r);
if (!ctxt->have_exception ||
- exception_type(ctxt->exception.vector) == EXCPT_TRAP)
+ exception_type(ctxt->exception.vector) == EXCPT_TRAP) {
+ kvm_rip_write(vcpu, ctxt->eip);
+ if (r == EMULATE_DONE && ctxt->tf)
+ kvm_vcpu_do_singlestep(vcpu, &r);
__kvm_set_rflags(vcpu, ctxt->eflags);
+ }
/*
* For STI, interrupts are shadowed; so KVM_REQ_EVENT will
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 62/83] x86/apic: Do not initialize LDR and DFR for bigsmp
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (60 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 61/83] KVM: x86: Dont update RIP or do single-step on faulting emulation Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 63/83] x86/apic: Include the LDR when clearing out APIC registers Greg Kroah-Hartman
` (26 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Thomas Gleixner, Bandan Das
From: Bandan Das <bsd@redhat.com>
commit bae3a8d3308ee69a7dbdf145911b18dfda8ade0d upstream.
Legacy apic init uses bigsmp for smp systems with 8 and more CPUs. The
bigsmp APIC implementation uses physical destination mode, but it
nevertheless initializes LDR and DFR. The LDR even ends up incorrectly with
multiple bit being set.
This does not cause a functional problem because LDR and DFR are ignored
when physical destination mode is active, but it triggered a problem on a
32-bit KVM guest which jumps into a kdump kernel.
The multiple bits set unearthed a bug in the KVM APIC implementation. The
code which creates the logical destination map for VCPUs ignores the
disabled state of the APIC and ends up overwriting an existing valid entry
and as a result, APIC calibration hangs in the guest during kdump
initialization.
Remove the bogus LDR/DFR initialization.
This is not intended to work around the KVM APIC bug. The LDR/DFR
ininitalization is wrong on its own.
The issue goes back into the pre git history. The fixes tag is the commit
in the bitkeeper import which introduced bigsmp support in 2003.
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Fixes: db7b9e9f26b8 ("[PATCH] Clustered APIC setup for >8 CPU systems")
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Bandan Das <bsd@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190826101513.5080-2-bsd@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/apic/bigsmp_32.c | 24 ++----------------------
1 file changed, 2 insertions(+), 22 deletions(-)
--- a/arch/x86/kernel/apic/bigsmp_32.c
+++ b/arch/x86/kernel/apic/bigsmp_32.c
@@ -37,32 +37,12 @@ static int bigsmp_early_logical_apicid(i
return early_per_cpu(x86_cpu_to_apicid, cpu);
}
-static inline unsigned long calculate_ldr(int cpu)
-{
- unsigned long val, id;
-
- val = apic_read(APIC_LDR) & ~APIC_LDR_MASK;
- id = per_cpu(x86_bios_cpu_apicid, cpu);
- val |= SET_APIC_LOGICAL_ID(id);
-
- return val;
-}
-
/*
- * Set up the logical destination ID.
- *
- * Intel recommends to set DFR, LDR and TPR before enabling
- * an APIC. See e.g. "AP-388 82489DX User's Manual" (Intel
- * document number 292116). So here it goes...
+ * bigsmp enables physical destination mode
+ * and doesn't use LDR and DFR
*/
static void bigsmp_init_apic_ldr(void)
{
- unsigned long val;
- int cpu = smp_processor_id();
-
- apic_write(APIC_DFR, APIC_DFR_FLAT);
- val = calculate_ldr(cpu);
- apic_write(APIC_LDR, val);
}
static void bigsmp_setup_apic_routing(void)
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 63/83] x86/apic: Include the LDR when clearing out APIC registers
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (61 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 62/83] x86/apic: Do not initialize LDR and DFR for bigsmp Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 64/83] mm/zsmalloc.c: fix race condition in zs_destroy_pool Greg Kroah-Hartman
` (25 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Bandan Das, Thomas Gleixner
From: Bandan Das <bsd@redhat.com>
commit 558682b5291937a70748d36fd9ba757fb25b99ae upstream.
Although APIC initialization will typically clear out the LDR before
setting it, the APIC cleanup code should reset the LDR.
This was discovered with a 32-bit KVM guest jumping into a kdump
kernel. The stale bits in the LDR triggered a bug in the KVM APIC
implementation which caused the destination mapping for VCPUs to be
corrupted.
Note that this isn't intended to paper over the KVM APIC bug. The kernel
has to clear the LDR when resetting the APIC registers except when X2APIC
is enabled.
This lacks a Fixes tag because missing to clear LDR goes way back into pre
git history.
[ tglx: Made x2apic_enabled a function call as required ]
Signed-off-by: Bandan Das <bsd@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190826101513.5080-3-bsd@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/apic/apic.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1067,6 +1067,10 @@ void clear_local_APIC(void)
apic_write(APIC_LVT0, v | APIC_LVT_MASKED);
v = apic_read(APIC_LVT1);
apic_write(APIC_LVT1, v | APIC_LVT_MASKED);
+ if (!x2apic_enabled()) {
+ v = apic_read(APIC_LDR) & ~APIC_LDR_MASK;
+ apic_write(APIC_LDR, v);
+ }
if (maxlvt >= 4) {
v = apic_read(APIC_LVTPC);
apic_write(APIC_LVTPC, v | APIC_LVT_MASKED);
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 64/83] mm/zsmalloc.c: fix race condition in zs_destroy_pool
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (62 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 63/83] x86/apic: Include the LDR when clearing out APIC registers Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 65/83] usb-storage: Add new JMS567 revision to unusual_devs Greg Kroah-Hartman
` (24 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Henry Burns, Sergey Senozhatsky,
Henry Burns, Minchan Kim, Shakeel Butt, Jonathan Adams,
Andrew Morton, Linus Torvalds, Sasha Levin
[ Upstream commit 701d678599d0c1623aaf4139c03eea260a75b027 ]
In zs_destroy_pool() we call flush_work(&pool->free_work). However, we
have no guarantee that migration isn't happening in the background at
that time.
Since migration can't directly free pages, it relies on free_work being
scheduled to free the pages. But there's nothing preventing an
in-progress migrate from queuing the work *after*
zs_unregister_migration() has called flush_work(). Which would mean
pages still pointing at the inode when we free it.
Since we know at destroy time all objects should be free, no new
migrations can come in (since zs_page_isolate() fails for fully-free
zspages). This means it is sufficient to track a "# isolated zspages"
count by class, and have the destroy logic ensure all such pages have
drained before proceeding. Keeping that state under the class spinlock
keeps the logic straightforward.
In this case a memory leak could lead to an eventual crash if compaction
hits the leaked page. This crash would only occur if people are
changing their zswap backend at runtime (which eventually starts
destruction).
Link: http://lkml.kernel.org/r/20190809181751.219326-2-henryburns@google.com
Fixes: 48b4800a1c6a ("zsmalloc: page migration support")
Signed-off-by: Henry Burns <henryburns@google.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Henry Burns <henrywolfeburns@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Jonathan Adams <jwadams@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
mm/zsmalloc.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 59 insertions(+), 2 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index f624cc2d91d98..ad8a34bd15ca7 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -52,6 +52,7 @@
#include <linux/zpool.h>
#include <linux/mount.h>
#include <linux/migrate.h>
+#include <linux/wait.h>
#include <linux/pagemap.h>
#define ZSPAGE_MAGIC 0x58
@@ -265,6 +266,10 @@ struct zs_pool {
#ifdef CONFIG_COMPACTION
struct inode *inode;
struct work_struct free_work;
+ /* A wait queue for when migration races with async_free_zspage() */
+ wait_queue_head_t migration_wait;
+ atomic_long_t isolated_pages;
+ bool destroying;
#endif
};
@@ -1951,6 +1956,19 @@ static void putback_zspage_deferred(struct zs_pool *pool,
}
+static inline void zs_pool_dec_isolated(struct zs_pool *pool)
+{
+ VM_BUG_ON(atomic_long_read(&pool->isolated_pages) <= 0);
+ atomic_long_dec(&pool->isolated_pages);
+ /*
+ * There's no possibility of racing, since wait_for_isolated_drain()
+ * checks the isolated count under &class->lock after enqueuing
+ * on migration_wait.
+ */
+ if (atomic_long_read(&pool->isolated_pages) == 0 && pool->destroying)
+ wake_up_all(&pool->migration_wait);
+}
+
static void replace_sub_page(struct size_class *class, struct zspage *zspage,
struct page *newpage, struct page *oldpage)
{
@@ -2020,6 +2038,7 @@ bool zs_page_isolate(struct page *page, isolate_mode_t mode)
*/
if (!list_empty(&zspage->list) && !is_zspage_isolated(zspage)) {
get_zspage_mapping(zspage, &class_idx, &fullness);
+ atomic_long_inc(&pool->isolated_pages);
remove_zspage(class, zspage, fullness);
}
@@ -2108,8 +2127,16 @@ int zs_page_migrate(struct address_space *mapping, struct page *newpage,
* Page migration is done so let's putback isolated zspage to
* the list if @page is final isolated subpage in the zspage.
*/
- if (!is_zspage_isolated(zspage))
+ if (!is_zspage_isolated(zspage)) {
+ /*
+ * We cannot race with zs_destroy_pool() here because we wait
+ * for isolation to hit zero before we start destroying.
+ * Also, we ensure that everyone can see pool->destroying before
+ * we start waiting.
+ */
putback_zspage_deferred(pool, class, zspage);
+ zs_pool_dec_isolated(pool);
+ }
reset_page(page);
put_page(page);
@@ -2161,8 +2188,8 @@ void zs_page_putback(struct page *page)
* so let's defer.
*/
putback_zspage_deferred(pool, class, zspage);
+ zs_pool_dec_isolated(pool);
}
-
spin_unlock(&class->lock);
}
@@ -2185,8 +2212,36 @@ static int zs_register_migration(struct zs_pool *pool)
return 0;
}
+static bool pool_isolated_are_drained(struct zs_pool *pool)
+{
+ return atomic_long_read(&pool->isolated_pages) == 0;
+}
+
+/* Function for resolving migration */
+static void wait_for_isolated_drain(struct zs_pool *pool)
+{
+
+ /*
+ * We're in the process of destroying the pool, so there are no
+ * active allocations. zs_page_isolate() fails for completely free
+ * zspages, so we need only wait for the zs_pool's isolated
+ * count to hit zero.
+ */
+ wait_event(pool->migration_wait,
+ pool_isolated_are_drained(pool));
+}
+
static void zs_unregister_migration(struct zs_pool *pool)
{
+ pool->destroying = true;
+ /*
+ * We need a memory barrier here to ensure global visibility of
+ * pool->destroying. Thus pool->isolated pages will either be 0 in which
+ * case we don't care, or it will be > 0 and pool->destroying will
+ * ensure that we wake up once isolation hits 0.
+ */
+ smp_mb();
+ wait_for_isolated_drain(pool); /* This can block */
flush_work(&pool->free_work);
iput(pool->inode);
}
@@ -2433,6 +2488,8 @@ struct zs_pool *zs_create_pool(const char *name)
if (!pool->name)
goto err;
+ init_waitqueue_head(&pool->migration_wait);
+
if (create_cache(pool))
goto err;
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 65/83] usb-storage: Add new JMS567 revision to unusual_devs
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (63 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 64/83] mm/zsmalloc.c: fix race condition in zs_destroy_pool Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 66/83] USB: cdc-wdm: fix race between write and disconnect due to flag abuse Greg Kroah-Hartman
` (23 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Henk van der Laan
From: Henk van der Laan <opensource@henkvdlaan.com>
commit 08d676d1685c2a29e4d0e1b0242324e564d4589e upstream.
Revision 0x0117 suffers from an identical issue to earlier revisions,
therefore it should be added to the quirks list.
Signed-off-by: Henk van der Laan <opensource@henkvdlaan.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190816200847.21366-1-opensource@henkvdlaan.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/storage/unusual_devs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -2119,7 +2119,7 @@ UNUSUAL_DEV( 0x14cd, 0x6600, 0x0201, 0x
US_FL_IGNORE_RESIDUE ),
/* Reported by Michael Büsch <m@bues.ch> */
-UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x0116,
+UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x0117,
"JMicron",
"USB to ATA/ATAPI Bridge",
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 66/83] USB: cdc-wdm: fix race between write and disconnect due to flag abuse
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (64 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 65/83] usb-storage: Add new JMS567 revision to unusual_devs Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:53 ` [PATCH 4.9 67/83] usb: chipidea: udc: dont do hardware access if gadget has stopped Greg Kroah-Hartman
` (22 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+d232cca6ec42c2edb3fc, Oliver Neukum
From: Oliver Neukum <oneukum@suse.com>
commit 1426bd2c9f7e3126e2678e7469dca9fd9fc6dd3e upstream.
In case of a disconnect an ongoing flush() has to be made fail.
Nevertheless we cannot be sure that any pending URB has already
finished, so although they will never succeed, they still must
not be touched.
The clean solution for this is to check for WDM_IN_USE
and WDM_DISCONNECTED in flush(). There is no point in ever
clearing WDM_IN_USE, as no further writes make sense.
The issue is as old as the driver.
Fixes: afba937e540c9 ("USB: CDC WDM driver")
Reported-by: syzbot+d232cca6ec42c2edb3fc@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190827103436.21143-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/class/cdc-wdm.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -597,10 +597,20 @@ static int wdm_flush(struct file *file,
{
struct wdm_device *desc = file->private_data;
- wait_event(desc->wait, !test_bit(WDM_IN_USE, &desc->flags));
+ wait_event(desc->wait,
+ /*
+ * needs both flags. We cannot do with one
+ * because resetting it would cause a race
+ * with write() yet we need to signal
+ * a disconnect
+ */
+ !test_bit(WDM_IN_USE, &desc->flags) ||
+ test_bit(WDM_DISCONNECTING, &desc->flags));
/* cannot dereference desc->intf if WDM_DISCONNECTING */
- if (desc->werr < 0 && !test_bit(WDM_DISCONNECTING, &desc->flags))
+ if (test_bit(WDM_DISCONNECTING, &desc->flags))
+ return -ENODEV;
+ if (desc->werr < 0)
dev_err(&desc->intf->dev, "Error in flush path: %d\n",
desc->werr);
@@ -968,8 +978,6 @@ static void wdm_disconnect(struct usb_in
spin_lock_irqsave(&desc->iuspin, flags);
set_bit(WDM_DISCONNECTING, &desc->flags);
set_bit(WDM_READ, &desc->flags);
- /* to terminate pending flushes */
- clear_bit(WDM_IN_USE, &desc->flags);
spin_unlock_irqrestore(&desc->iuspin, flags);
wake_up_all(&desc->wait);
mutex_lock(&desc->rlock);
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 67/83] usb: chipidea: udc: dont do hardware access if gadget has stopped
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (65 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 66/83] USB: cdc-wdm: fix race between write and disconnect due to flag abuse Greg Kroah-Hartman
@ 2019-09-04 17:53 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 68/83] usb: host: ohci: fix a race condition between shutdown and irq Greg Kroah-Hartman
` (21 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:53 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Peter Chen
From: Peter Chen <peter.chen@nxp.com>
commit cbe85c88ce80fb92956a0793518d415864dcead8 upstream.
After _gadget_stop_activity is executed, we can consider the hardware
operation for gadget has finished, and the udc can be stopped and enter
low power mode. So, any later hardware operations (from usb_ep_ops APIs
or usb_gadget_ops APIs) should be considered invalid, any deinitializatons
has been covered at _gadget_stop_activity.
I meet this problem when I plug out usb cable from PC using mass_storage
gadget, my callstack like: vbus interrupt->.vbus_session->
composite_disconnect ->pm_runtime_put_sync(&_gadget->dev),
the composite_disconnect will call fsg_disable, but fsg_disable calls
usb_ep_disable using async way, there are register accesses for
usb_ep_disable. So sometimes, I get system hang due to visit register
without clock, sometimes not.
The Linux Kernel USB maintainer Alan Stern suggests this kinds of solution.
See: http://marc.info/?l=linux-usb&m=138541769810983&w=2.
Cc: <stable@vger.kernel.org> #v4.9+
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20190820020503.27080-2-peter.chen@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/chipidea/udc.c | 32 ++++++++++++++++++++++++--------
1 file changed, 24 insertions(+), 8 deletions(-)
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -709,12 +709,6 @@ static int _gadget_stop_activity(struct
struct ci_hdrc *ci = container_of(gadget, struct ci_hdrc, gadget);
unsigned long flags;
- spin_lock_irqsave(&ci->lock, flags);
- ci->gadget.speed = USB_SPEED_UNKNOWN;
- ci->remote_wakeup = 0;
- ci->suspended = 0;
- spin_unlock_irqrestore(&ci->lock, flags);
-
/* flush all endpoints */
gadget_for_each_ep(ep, gadget) {
usb_ep_fifo_flush(ep);
@@ -732,6 +726,12 @@ static int _gadget_stop_activity(struct
ci->status = NULL;
}
+ spin_lock_irqsave(&ci->lock, flags);
+ ci->gadget.speed = USB_SPEED_UNKNOWN;
+ ci->remote_wakeup = 0;
+ ci->suspended = 0;
+ spin_unlock_irqrestore(&ci->lock, flags);
+
return 0;
}
@@ -1306,6 +1306,10 @@ static int ep_disable(struct usb_ep *ep)
return -EBUSY;
spin_lock_irqsave(hwep->lock, flags);
+ if (hwep->ci->gadget.speed == USB_SPEED_UNKNOWN) {
+ spin_unlock_irqrestore(hwep->lock, flags);
+ return 0;
+ }
/* only internal SW should disable ctrl endpts */
@@ -1395,6 +1399,10 @@ static int ep_queue(struct usb_ep *ep, s
return -EINVAL;
spin_lock_irqsave(hwep->lock, flags);
+ if (hwep->ci->gadget.speed == USB_SPEED_UNKNOWN) {
+ spin_unlock_irqrestore(hwep->lock, flags);
+ return 0;
+ }
retval = _ep_queue(ep, req, gfp_flags);
spin_unlock_irqrestore(hwep->lock, flags);
return retval;
@@ -1418,8 +1426,8 @@ static int ep_dequeue(struct usb_ep *ep,
return -EINVAL;
spin_lock_irqsave(hwep->lock, flags);
-
- hw_ep_flush(hwep->ci, hwep->num, hwep->dir);
+ if (hwep->ci->gadget.speed != USB_SPEED_UNKNOWN)
+ hw_ep_flush(hwep->ci, hwep->num, hwep->dir);
list_for_each_entry_safe(node, tmpnode, &hwreq->tds, td) {
dma_pool_free(hwep->td_pool, node->ptr, node->dma);
@@ -1490,6 +1498,10 @@ static void ep_fifo_flush(struct usb_ep
}
spin_lock_irqsave(hwep->lock, flags);
+ if (hwep->ci->gadget.speed == USB_SPEED_UNKNOWN) {
+ spin_unlock_irqrestore(hwep->lock, flags);
+ return;
+ }
hw_ep_flush(hwep->ci, hwep->num, hwep->dir);
@@ -1558,6 +1570,10 @@ static int ci_udc_wakeup(struct usb_gadg
int ret = 0;
spin_lock_irqsave(&ci->lock, flags);
+ if (ci->gadget.speed == USB_SPEED_UNKNOWN) {
+ spin_unlock_irqrestore(&ci->lock, flags);
+ return 0;
+ }
if (!ci->remote_wakeup) {
ret = -EOPNOTSUPP;
goto out;
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 68/83] usb: host: ohci: fix a race condition between shutdown and irq
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (66 preceding siblings ...)
2019-09-04 17:53 ` [PATCH 4.9 67/83] usb: chipidea: udc: dont do hardware access if gadget has stopped Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 69/83] usb: host: xhci: rcar: Fix typo in compatible string matching Greg Kroah-Hartman
` (20 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Yoshihiro Shimoda, Alan Stern
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
commit a349b95d7ca0cea71be4a7dac29830703de7eb62 upstream.
This patch fixes an issue that the following error is
possible to happen when ohci hardware causes an interruption
and the system is shutting down at the same time.
[ 34.851754] usb 2-1: USB disconnect, device number 2
[ 35.166658] irq 156: nobody cared (try booting with the "irqpoll" option)
[ 35.173445] CPU: 0 PID: 22 Comm: kworker/0:1 Not tainted 5.3.0-rc5 #85
[ 35.179964] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)
[ 35.187886] Workqueue: usb_hub_wq hub_event
[ 35.192063] Call trace:
[ 35.194509] dump_backtrace+0x0/0x150
[ 35.198165] show_stack+0x14/0x20
[ 35.201475] dump_stack+0xa0/0xc4
[ 35.204785] __report_bad_irq+0x34/0xe8
[ 35.208614] note_interrupt+0x2cc/0x318
[ 35.212446] handle_irq_event_percpu+0x5c/0x88
[ 35.216883] handle_irq_event+0x48/0x78
[ 35.220712] handle_fasteoi_irq+0xb4/0x188
[ 35.224802] generic_handle_irq+0x24/0x38
[ 35.228804] __handle_domain_irq+0x5c/0xb0
[ 35.232893] gic_handle_irq+0x58/0xa8
[ 35.236548] el1_irq+0xb8/0x180
[ 35.239681] __do_softirq+0x94/0x23c
[ 35.243253] irq_exit+0xd0/0xd8
[ 35.246387] __handle_domain_irq+0x60/0xb0
[ 35.250475] gic_handle_irq+0x58/0xa8
[ 35.254130] el1_irq+0xb8/0x180
[ 35.257268] kernfs_find_ns+0x5c/0x120
[ 35.261010] kernfs_find_and_get_ns+0x3c/0x60
[ 35.265361] sysfs_unmerge_group+0x20/0x68
[ 35.269454] dpm_sysfs_remove+0x2c/0x68
[ 35.273284] device_del+0x80/0x370
[ 35.276683] hid_destroy_device+0x28/0x60
[ 35.280686] usbhid_disconnect+0x4c/0x80
[ 35.284602] usb_unbind_interface+0x6c/0x268
[ 35.288867] device_release_driver_internal+0xe4/0x1b0
[ 35.293998] device_release_driver+0x14/0x20
[ 35.298261] bus_remove_device+0x110/0x128
[ 35.302350] device_del+0x148/0x370
[ 35.305832] usb_disable_device+0x8c/0x1d0
[ 35.309921] usb_disconnect+0xc8/0x2d0
[ 35.313663] hub_event+0x6e0/0x1128
[ 35.317146] process_one_work+0x1e0/0x320
[ 35.321148] worker_thread+0x40/0x450
[ 35.324805] kthread+0x124/0x128
[ 35.328027] ret_from_fork+0x10/0x18
[ 35.331594] handlers:
[ 35.333862] [<0000000079300c1d>] usb_hcd_irq
[ 35.338126] [<0000000079300c1d>] usb_hcd_irq
[ 35.342389] Disabling IRQ #156
ohci_shutdown() disables all the interrupt and rh_state is set to
OHCI_RH_HALTED. In other hand, ohci_irq() is possible to enable
OHCI_INTR_SF and OHCI_INTR_MIE on ohci_irq(). Note that OHCI_INTR_SF
is possible to be set by start_ed_unlink() which is called:
ohci_irq()
-> process_done_list()
-> takeback_td()
-> start_ed_unlink()
So, ohci_irq() has the following condition, the issue happens by
&ohci->regs->intrenable = OHCI_INTR_MIE | OHCI_INTR_SF and
ohci->rh_state = OHCI_RH_HALTED:
/* interrupt for some other device? */
if (ints == 0 || unlikely(ohci->rh_state == OHCI_RH_HALTED))
return IRQ_NOTMINE;
To fix the issue, ohci_shutdown() holds the spin lock while disabling
the interruption and changing the rh_state flag to prevent reenable
the OHCI_INTR_MIE unexpectedly. Note that io_watchdog_func() also
calls the ohci_shutdown() and it already held the spin lock, so that
the patch makes a new function as _ohci_shutdown().
This patch is inspired by a Renesas R-Car Gen3 BSP patch
from Tho Vu.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/1566877910-6020-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/ohci-hcd.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -417,8 +417,7 @@ static void ohci_usb_reset (struct ohci_
* other cases where the next software may expect clean state from the
* "firmware". this is bus-neutral, unlike shutdown() methods.
*/
-static void
-ohci_shutdown (struct usb_hcd *hcd)
+static void _ohci_shutdown(struct usb_hcd *hcd)
{
struct ohci_hcd *ohci;
@@ -434,6 +433,16 @@ ohci_shutdown (struct usb_hcd *hcd)
ohci->rh_state = OHCI_RH_HALTED;
}
+static void ohci_shutdown(struct usb_hcd *hcd)
+{
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ unsigned long flags;
+
+ spin_lock_irqsave(&ohci->lock, flags);
+ _ohci_shutdown(hcd);
+ spin_unlock_irqrestore(&ohci->lock, flags);
+}
+
/*-------------------------------------------------------------------------*
* HC functions
*-------------------------------------------------------------------------*/
@@ -752,7 +761,7 @@ static void io_watchdog_func(unsigned lo
died:
usb_hc_died(ohci_to_hcd(ohci));
ohci_dump(ohci);
- ohci_shutdown(ohci_to_hcd(ohci));
+ _ohci_shutdown(ohci_to_hcd(ohci));
goto done;
} else {
/* No write back because the done queue was empty */
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 69/83] usb: host: xhci: rcar: Fix typo in compatible string matching
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (67 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 68/83] usb: host: ohci: fix a race condition between shutdown and irq Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 70/83] USB: storage: ums-realtek: Update module parameter description for auto_delink_en Greg Kroah-Hartman
` (19 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Geert Uytterhoeven, Yoshihiro Shimoda
From: Geert Uytterhoeven <geert+renesas@glider.be>
commit 636bd02a7ba9025ff851d0cfb92768c8fa865859 upstream.
It's spelled "renesas", not "renensas".
Due to this typo, RZ/G1M and RZ/G1N were not covered by the check.
Fixes: 2dc240a3308b ("usb: host: xhci: rcar: retire use of xhci_plat_type_is()")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20190827125112.12192-1-geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-rcar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-rcar.c
+++ b/drivers/usb/host/xhci-rcar.c
@@ -84,7 +84,7 @@ static int xhci_rcar_is_gen2(struct devi
return of_device_is_compatible(node, "renesas,xhci-r8a7790") ||
of_device_is_compatible(node, "renesas,xhci-r8a7791") ||
of_device_is_compatible(node, "renesas,xhci-r8a7793") ||
- of_device_is_compatible(node, "renensas,rcar-gen2-xhci");
+ of_device_is_compatible(node, "renesas,rcar-gen2-xhci");
}
static int xhci_rcar_is_gen3(struct device *dev)
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 70/83] USB: storage: ums-realtek: Update module parameter description for auto_delink_en
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (68 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 69/83] usb: host: xhci: rcar: Fix typo in compatible string matching Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 71/83] USB: storage: ums-realtek: Whitelist auto-delink support Greg Kroah-Hartman
` (18 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Kai-Heng Feng
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
commit f6445b6b2f2bb1745080af4a0926049e8bca2617 upstream.
The option named "auto_delink_en" is a bit misleading, as setting it to
false doesn't really disable auto-delink but let auto-delink be firmware
controlled.
Update the description to reflect the real usage of this parameter.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190827173450.13572-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/storage/realtek_cr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/storage/realtek_cr.c
+++ b/drivers/usb/storage/realtek_cr.c
@@ -51,7 +51,7 @@ MODULE_VERSION("1.03");
static int auto_delink_en = 1;
module_param(auto_delink_en, int, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(auto_delink_en, "enable auto delink");
+MODULE_PARM_DESC(auto_delink_en, "auto delink mode (0=firmware, 1=software [default])");
#ifdef CONFIG_REALTEK_AUTOPM
static int ss_en = 1;
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 71/83] USB: storage: ums-realtek: Whitelist auto-delink support
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (69 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 70/83] USB: storage: ums-realtek: Update module parameter description for auto_delink_en Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 72/83] ptrace,x86: Make user_64bit_mode() available to 32-bit builds Greg Kroah-Hartman
` (17 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Kai-Heng Feng, Alan Stern
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
commit 1902a01e2bcc3abd7c9a18dc05e78c7ab4a53c54 upstream.
Auto-delink requires writing special registers to ums-realtek devices.
Unconditionally enable auto-delink may break newer devices.
So only enable auto-delink by default for the original three IDs,
0x0138, 0x0158 and 0x0159.
Realtek is working on a patch to properly support auto-delink for other
IDs.
BugLink: https://bugs.launchpad.net/bugs/1838886
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190827173450.13572-2-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/storage/realtek_cr.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/drivers/usb/storage/realtek_cr.c
+++ b/drivers/usb/storage/realtek_cr.c
@@ -1010,12 +1010,15 @@ static int init_realtek_cr(struct us_dat
goto INIT_FAIL;
}
- if (CHECK_FW_VER(chip, 0x5888) || CHECK_FW_VER(chip, 0x5889) ||
- CHECK_FW_VER(chip, 0x5901))
- SET_AUTO_DELINK(chip);
- if (STATUS_LEN(chip) == 16) {
- if (SUPPORT_AUTO_DELINK(chip))
+ if (CHECK_PID(chip, 0x0138) || CHECK_PID(chip, 0x0158) ||
+ CHECK_PID(chip, 0x0159)) {
+ if (CHECK_FW_VER(chip, 0x5888) || CHECK_FW_VER(chip, 0x5889) ||
+ CHECK_FW_VER(chip, 0x5901))
SET_AUTO_DELINK(chip);
+ if (STATUS_LEN(chip) == 16) {
+ if (SUPPORT_AUTO_DELINK(chip))
+ SET_AUTO_DELINK(chip);
+ }
}
#ifdef CONFIG_REALTEK_AUTOPM
if (ss_en)
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 72/83] ptrace,x86: Make user_64bit_mode() available to 32-bit builds
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (70 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 71/83] USB: storage: ums-realtek: Whitelist auto-delink support Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 73/83] uprobes/x86: Fix detection of 32-bit user mode Greg Kroah-Hartman
` (16 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Borislav Petkov, Ricardo Neri,
Thomas Gleixner, Michael S. Tsirkin, Peter Zijlstra, Dave Hansen,
ricardo.neri, Adrian Hunter, Paul Gortmaker, Huang Rui,
Qiaowei Ren, Shuah Khan, Kees Cook, Jonathan Corbet, Jiri Slaby,
Dmitry Vyukov, Ravi V. Shankar, Chris Metcalf, Brian Gerst,
Arnaldo Carvalho de Melo, Andy Lutomirski, Colin Ian King,
Chen Yucong, Adam Buchbinder, Vlastimil Babka, Lorenzo Stoakes,
Masami Hiramatsu, Paolo Bonzini, Andrew Morton, Thomas Garnier,
Sasha Levin
[ Upstream commit e27c310af5c05cf876d9cad006928076c27f54d4 ]
In its current form, user_64bit_mode() can only be used when CONFIG_X86_64
is selected. This implies that code built with CONFIG_X86_64=n cannot use
it. If a piece of code needs to be built for both CONFIG_X86_64=y and
CONFIG_X86_64=n and wants to use this function, it needs to wrap it in
an #ifdef/#endif; potentially, in multiple places.
This can be easily avoided with a single #ifdef/#endif pair within
user_64bit_mode() itself.
Suggested-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: ricardo.neri@intel.com
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: Qiaowei Ren <qiaowei.ren@intel.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Chen Yucong <slaoub@gmail.com>
Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Garnier <thgarnie@google.com>
Link: https://lkml.kernel.org/r/1509135945-13762-4-git-send-email-ricardo.neri-calderon@linux.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/include/asm/ptrace.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 2b5d686ea9f37..ea78a8438a8af 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -115,9 +115,9 @@ static inline int v8086_mode(struct pt_regs *regs)
#endif
}
-#ifdef CONFIG_X86_64
static inline bool user_64bit_mode(struct pt_regs *regs)
{
+#ifdef CONFIG_X86_64
#ifndef CONFIG_PARAVIRT
/*
* On non-paravirt systems, this is the only long mode CPL 3
@@ -128,8 +128,12 @@ static inline bool user_64bit_mode(struct pt_regs *regs)
/* Headers are too twisted for this to go in paravirt.h. */
return regs->cs == __USER_CS || regs->cs == pv_info.extra_user_64bit_cs;
#endif
+#else /* !CONFIG_X86_64 */
+ return false;
+#endif
}
+#ifdef CONFIG_X86_64
#define current_user_stack_pointer() current_pt_regs()->sp
#define compat_user_stack_pointer() current_pt_regs()->sp
#endif
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 73/83] uprobes/x86: Fix detection of 32-bit user mode
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (71 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 72/83] ptrace,x86: Make user_64bit_mode() available to 32-bit builds Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 74/83] mmc: sdhci-of-at91: add quirk for broken HS200 Greg Kroah-Hartman
` (15 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sebastian Mayr, Thomas Gleixner,
Masami Hiramatsu, Dmitry Safonov, Oleg Nesterov,
Srikar Dronamraju, Sasha Levin
[ Upstream commit 9212ec7d8357ea630031e89d0d399c761421c83b ]
32-bit processes running on a 64-bit kernel are not always detected
correctly, causing the process to crash when uretprobes are installed.
The reason for the crash is that in_ia32_syscall() is used to determine the
process's mode, which only works correctly when called from a syscall.
In the case of uretprobes, however, the function is called from a exception
and always returns 'false' on a 64-bit kernel. In consequence this leads to
corruption of the process's return address.
Fix this by using user_64bit_mode() instead of in_ia32_syscall(), which
is correct in any situation.
[ tglx: Add a comment and the following historical info ]
This should have been detected by the rename which happened in commit
abfb9498ee13 ("x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall()")
which states in the changelog:
The is_ia32_task()/is_x32_task() function names are a big misnomer: they
suggests that the compat-ness of a system call is a task property, which
is not true, the compatness of a system call purely depends on how it
was invoked through the system call layer.
.....
and then it went and blindly renamed every call site.
Sadly enough this was already mentioned here:
8faaed1b9f50 ("uprobes/x86: Introduce sizeof_long(), cleanup adjust_ret_addr() and
arch_uretprobe_hijack_return_addr()")
where the changelog says:
TODO: is_ia32_task() is not what we actually want, TS_COMPAT does
not necessarily mean 32bit. Fortunately syscall-like insns can't be
probed so it actually works, but it would be better to rename and
use is_ia32_frame().
and goes all the way back to:
0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")
Oh well. 7+ years until someone actually tried a uretprobe on a 32bit
process on a 64bit kernel....
Fixes: 0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")
Signed-off-by: Sebastian Mayr <me@sam.st>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190728152617.7308-1-me@sam.st
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/kernel/uprobes.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index e78a6b1db74b0..e35466afe989d 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -514,9 +514,12 @@ struct uprobe_xol_ops {
void (*abort)(struct arch_uprobe *, struct pt_regs *);
};
-static inline int sizeof_long(void)
+static inline int sizeof_long(struct pt_regs *regs)
{
- return in_ia32_syscall() ? 4 : 8;
+ /*
+ * Check registers for mode as in_xxx_syscall() does not apply here.
+ */
+ return user_64bit_mode(regs) ? 8 : 4;
}
static int default_pre_xol_op(struct arch_uprobe *auprobe, struct pt_regs *regs)
@@ -527,9 +530,9 @@ static int default_pre_xol_op(struct arch_uprobe *auprobe, struct pt_regs *regs)
static int push_ret_address(struct pt_regs *regs, unsigned long ip)
{
- unsigned long new_sp = regs->sp - sizeof_long();
+ unsigned long new_sp = regs->sp - sizeof_long(regs);
- if (copy_to_user((void __user *)new_sp, &ip, sizeof_long()))
+ if (copy_to_user((void __user *)new_sp, &ip, sizeof_long(regs)))
return -EFAULT;
regs->sp = new_sp;
@@ -562,7 +565,7 @@ static int default_post_xol_op(struct arch_uprobe *auprobe, struct pt_regs *regs
long correction = utask->vaddr - utask->xol_vaddr;
regs->ip += correction;
} else if (auprobe->defparam.fixups & UPROBE_FIX_CALL) {
- regs->sp += sizeof_long(); /* Pop incorrect return address */
+ regs->sp += sizeof_long(regs); /* Pop incorrect return address */
if (push_ret_address(regs, utask->vaddr + auprobe->defparam.ilen))
return -ERESTART;
}
@@ -671,7 +674,7 @@ static int branch_post_xol_op(struct arch_uprobe *auprobe, struct pt_regs *regs)
* "call" insn was executed out-of-line. Just restore ->sp and restart.
* We could also restore ->ip and try to call branch_emulate_op() again.
*/
- regs->sp += sizeof_long();
+ regs->sp += sizeof_long(regs);
return -ERESTART;
}
@@ -962,7 +965,7 @@ bool arch_uprobe_skip_sstep(struct arch_uprobe *auprobe, struct pt_regs *regs)
unsigned long
arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr, struct pt_regs *regs)
{
- int rasize = sizeof_long(), nleft;
+ int rasize = sizeof_long(regs), nleft;
unsigned long orig_ret_vaddr = 0; /* clear high bits for 32-bit apps */
if (copy_from_user(&orig_ret_vaddr, (void __user *)regs->sp, rasize))
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 74/83] mmc: sdhci-of-at91: add quirk for broken HS200
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (72 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 73/83] uprobes/x86: Fix detection of 32-bit user mode Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 75/83] mmc: core: Fix init of SD cards reporting an invalid VDD range Greg Kroah-Hartman
` (14 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eugen Hristev, Ludovic Desroches,
Adrian Hunter, Ulf Hansson
From: Eugen Hristev <eugen.hristev@microchip.com>
commit 7871aa60ae0086fe4626abdf5ed13eeddf306c61 upstream.
HS200 is not implemented in the driver, but the controller claims it
through caps. Remove it via a quirk, to make sure the mmc core do not try
to enable HS200, as it causes the eMMC initialization to fail.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: bb5f8ea4d514 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC")
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/sdhci-of-at91.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/mmc/host/sdhci-of-at91.c
+++ b/drivers/mmc/host/sdhci-of-at91.c
@@ -317,6 +317,9 @@ static int sdhci_at91_probe(struct platf
pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
pm_runtime_use_autosuspend(&pdev->dev);
+ /* HS200 is broken at this moment */
+ host->quirks2 = SDHCI_QUIRK2_BROKEN_HS200;
+
ret = sdhci_add_host(host);
if (ret)
goto pm_runtime_disable;
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 75/83] mmc: core: Fix init of SD cards reporting an invalid VDD range
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (73 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 74/83] mmc: sdhci-of-at91: add quirk for broken HS200 Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 76/83] stm class: Fix a double free of stm_source_device Greg Kroah-Hartman
` (13 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Philip Langdale, Ulf Hansson,
Manuel Presnitz
From: Ulf Hansson <ulf.hansson@linaro.org>
commit 72741084d903e65e121c27bd29494d941729d4a1 upstream.
The OCR register defines the supported range of VDD voltages for SD cards.
However, it has turned out that some SD cards reports an invalid voltage
range, for example having bit7 set.
When a host supports MMC_CAP2_FULL_PWR_CYCLE and some of the voltages from
the invalid VDD range, this triggers the core to run a power cycle of the
card to try to initialize it at the lowest common supported voltage.
Obviously this fails, since the card can't support it.
Let's fix this problem, by clearing invalid bits from the read OCR register
for SD cards, before proceeding with the VDD voltage negotiation.
Cc: stable@vger.kernel.org
Reported-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Philip Langdale <philipl@overt.org>
Tested-by: Philip Langdale <philipl@overt.org>
Tested-by: Manuel Presnitz <mail@mpy.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/core/sd.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -1259,6 +1259,12 @@ int mmc_attach_sd(struct mmc_host *host)
goto err;
}
+ /*
+ * Some SD cards claims an out of spec VDD voltage range. Let's treat
+ * these bits as being in-valid and especially also bit7.
+ */
+ ocr &= ~0x7FFF;
+
rocr = mmc_select_voltage(host, ocr);
/*
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 76/83] stm class: Fix a double free of stm_source_device
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (74 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 75/83] mmc: core: Fix init of SD cards reporting an invalid VDD range Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 77/83] VMCI: Release resource if the work is already queued Greg Kroah-Hartman
` (12 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ding Xiang, Alexander Shishkin
From: Ding Xiang <dingxiang@cmss.chinamobile.com>
commit 961b6ffe0e2c403b09a8efe4a2e986b3c415391a upstream.
In the error path of stm_source_register_device(), the kfree is
unnecessary, as the put_device() before it ends up calling
stm_source_device_release() to free stm_source_device, leading to
a double free at the outer kfree() call. Remove it.
Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Fixes: 7bd1d4093c2fa ("stm class: Introduce an abstraction for System Trace Module devices")
Link: https://lore.kernel.org/linux-arm-kernel/1563354988-23826-1-git-send-email-dingxiang@cmss.chinamobile.com/
Cc: stable@vger.kernel.org # v4.4+
Link: https://lore.kernel.org/r/20190821074955.3925-2-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwtracing/stm/core.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -1107,7 +1107,6 @@ int stm_source_register_device(struct de
err:
put_device(&src->dev);
- kfree(src);
return err;
}
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 77/83] VMCI: Release resource if the work is already queued
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (75 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 76/83] stm class: Fix a double free of stm_source_device Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 78/83] Revert "cfg80211: fix processing world regdomain when non modular" Greg Kroah-Hartman
` (11 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Francois Rigault, Jorgen Hansen,
Adit Ranadive, Alexios Zavras, Vishnu DASA, Nadav Amit
From: Nadav Amit <namit@vmware.com>
commit ba03a9bbd17b149c373c0ea44017f35fc2cd0f28 upstream.
Francois reported that VMware balloon gets stuck after a balloon reset,
when the VMCI doorbell is removed. A similar error can occur when the
balloon driver is removed with the following splat:
[ 1088.622000] INFO: task modprobe:3565 blocked for more than 120 seconds.
[ 1088.622035] Tainted: G W 5.2.0 #4
[ 1088.622087] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1088.622205] modprobe D 0 3565 1450 0x00000000
[ 1088.622210] Call Trace:
[ 1088.622246] __schedule+0x2a8/0x690
[ 1088.622248] schedule+0x2d/0x90
[ 1088.622250] schedule_timeout+0x1d3/0x2f0
[ 1088.622252] wait_for_completion+0xba/0x140
[ 1088.622320] ? wake_up_q+0x80/0x80
[ 1088.622370] vmci_resource_remove+0xb9/0xc0 [vmw_vmci]
[ 1088.622373] vmci_doorbell_destroy+0x9e/0xd0 [vmw_vmci]
[ 1088.622379] vmballoon_vmci_cleanup+0x6e/0xf0 [vmw_balloon]
[ 1088.622381] vmballoon_exit+0x18/0xcc8 [vmw_balloon]
[ 1088.622394] __x64_sys_delete_module+0x146/0x280
[ 1088.622408] do_syscall_64+0x5a/0x130
[ 1088.622410] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1088.622415] RIP: 0033:0x7f54f62791b7
[ 1088.622421] Code: Bad RIP value.
[ 1088.622421] RSP: 002b:00007fff2a949008 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[ 1088.622426] RAX: ffffffffffffffda RBX: 000055dff8b55d00 RCX: 00007f54f62791b7
[ 1088.622426] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055dff8b55d68
[ 1088.622427] RBP: 000055dff8b55d00 R08: 00007fff2a947fb1 R09: 0000000000000000
[ 1088.622427] R10: 00007f54f62f5cc0 R11: 0000000000000206 R12: 000055dff8b55d68
[ 1088.622428] R13: 0000000000000001 R14: 000055dff8b55d68 R15: 00007fff2a94a3f0
The cause for the bug is that when the "delayed" doorbell is invoked, it
takes a reference on the doorbell entry and schedules work that is
supposed to run the appropriate code and drop the doorbell entry
reference. The code ignores the fact that if the work is already queued,
it will not be scheduled to run one more time. As a result one of the
references would not be dropped. When the code waits for the reference
to get to zero, during balloon reset or module removal, it gets stuck.
Fix it. Drop the reference if schedule_work() indicates that the work is
already queued.
Note that this bug got more apparent (or apparent at all) due to
commit ce664331b248 ("vmw_balloon: VMCI_DOORBELL_SET does not check status").
Fixes: 83e2ec765be03 ("VMCI: doorbell implementation.")
Reported-by: Francois Rigault <rigault.francois@gmail.com>
Cc: Jorgen Hansen <jhansen@vmware.com>
Cc: Adit Ranadive <aditr@vmware.com>
Cc: Alexios Zavras <alexios.zavras@intel.com>
Cc: Vishnu DASA <vdasa@vmware.com>
Cc: stable@vger.kernel.org
Signed-off-by: Nadav Amit <namit@vmware.com>
Reviewed-by: Vishnu Dasa <vdasa@vmware.com>
Link: https://lore.kernel.org/r/20190820202638.49003-1-namit@vmware.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/vmw_vmci/vmci_doorbell.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/misc/vmw_vmci/vmci_doorbell.c
+++ b/drivers/misc/vmw_vmci/vmci_doorbell.c
@@ -318,7 +318,8 @@ int vmci_dbell_host_context_notify(u32 s
entry = container_of(resource, struct dbell_entry, resource);
if (entry->run_delayed) {
- schedule_work(&entry->work);
+ if (!schedule_work(&entry->work))
+ vmci_resource_put(resource);
} else {
entry->notify_cb(entry->client_data);
vmci_resource_put(resource);
@@ -366,7 +367,8 @@ static void dbell_fire_entries(u32 notif
atomic_read(&dbell->active) == 1) {
if (dbell->run_delayed) {
vmci_resource_get(&dbell->resource);
- schedule_work(&dbell->work);
+ if (!schedule_work(&dbell->work))
+ vmci_resource_put(&dbell->resource);
} else {
dbell->notify_cb(dbell->client_data);
}
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 78/83] Revert "cfg80211: fix processing world regdomain when non modular"
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (76 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 77/83] VMCI: Release resource if the work is already queued Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 79/83] mac80211: fix possible sta leak Greg Kroah-Hartman
` (10 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Robert Hodaszi, Johannes Berg
From: Hodaszi, Robert <Robert.Hodaszi@digi.com>
commit 0d31d4dbf38412f5b8b11b4511d07b840eebe8cb upstream.
This reverts commit 96cce12ff6e0 ("cfg80211: fix processing world
regdomain when non modular").
Re-triggering a reg_process_hint with the last request on all events,
can make the regulatory domain fail in case of multiple WiFi modules. On
slower boards (espacially with mdev), enumeration of the WiFi modules
can end up in an intersected regulatory domain, and user cannot set it
with 'iw reg set' anymore.
This is happening, because:
- 1st module enumerates, queues up a regulatory request
- request gets processed by __reg_process_hint_driver():
- checks if previous was set by CORE -> yes
- checks if regulator domain changed -> yes, from '00' to e.g. 'US'
-> sends request to the 'crda'
- 2nd module enumerates, queues up a regulator request (which triggers
the reg_todo() work)
- reg_todo() -> reg_process_pending_hints() sees, that the last request
is not processed yet, so it tries to process it again.
__reg_process_hint driver() will run again, and:
- checks if the last request's initiator was the core -> no, it was
the driver (1st WiFi module)
- checks, if the previous initiator was the driver -> yes
- checks if the regulator domain changed -> yes, it was '00' (set by
core, and crda call did not return yet), and should be changed to 'US'
------> __reg_process_hint_driver calls an intersect
Besides, the reg_process_hint call with the last request is meaningless
since the crda call has a timeout work. If that timeout expires, the
first module's request will lost.
Cc: stable@vger.kernel.org
Fixes: 96cce12ff6e0 ("cfg80211: fix processing world regdomain when non modular")
Signed-off-by: Robert Hodaszi <robert.hodaszi@digi.com>
Link: https://lore.kernel.org/r/20190614131600.GA13897@a1-hr
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/wireless/reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -2165,7 +2165,7 @@ static void reg_process_pending_hints(vo
/* When last_request->processed becomes true this will be rescheduled */
if (lr && !lr->processed) {
- reg_process_hint(lr);
+ pr_debug("Pending regulatory request, waiting for it to be processed...\n");
return;
}
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 79/83] mac80211: fix possible sta leak
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (77 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 78/83] Revert "cfg80211: fix processing world regdomain when non modular" Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 80/83] KVM: arm/arm64: vgic: Fix potential deadlock when ap_list is long Greg Kroah-Hartman
` (9 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
commit 5fd2f91ad483baffdbe798f8a08f1b41442d1e24 upstream.
If TDLS station addition is rejected, the sta memory is leaked.
Avoid this by moving the check before the allocation.
Cc: stable@vger.kernel.org
Fixes: 7ed5285396c2 ("mac80211: don't initiate TDLS connection if station is not associated to AP")
Link: https://lore.kernel.org/r/20190801073033.7892-1-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mac80211/cfg.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1418,6 +1418,11 @@ static int ieee80211_add_station(struct
if (is_multicast_ether_addr(mac))
return -EINVAL;
+ if (params->sta_flags_set & BIT(NL80211_STA_FLAG_TDLS_PEER) &&
+ sdata->vif.type == NL80211_IFTYPE_STATION &&
+ !sdata->u.mgd.associated)
+ return -EINVAL;
+
sta = sta_info_alloc(sdata, mac, GFP_KERNEL);
if (!sta)
return -ENOMEM;
@@ -1425,10 +1430,6 @@ static int ieee80211_add_station(struct
if (params->sta_flags_set & BIT(NL80211_STA_FLAG_TDLS_PEER))
sta->sta.tdls = true;
- if (sta->sta.tdls && sdata->vif.type == NL80211_IFTYPE_STATION &&
- !sdata->u.mgd.associated)
- return -EINVAL;
-
err = sta_apply_parameters(local, sta, params);
if (err) {
sta_info_free(local, sta);
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH 4.9 80/83] KVM: arm/arm64: vgic: Fix potential deadlock when ap_list is long
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (78 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 79/83] mac80211: fix possible sta leak Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 81/83] KVM: arm/arm64: vgic-v2: Handle SGI bits in GICD_I{S,C}PENDR0 as WI Greg Kroah-Hartman
` (8 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Zenghui Yu, Heyi Guo, Marc Zyngier,
Will Deacon, Sasha Levin
[ Upstream commit d4a8061a7c5f7c27a2dc002ee4cb89b3e6637e44 ]
If the ap_list is longer than 256 entries, merge_final() in list_sort()
will call the comparison callback with the same element twice, causing
a deadlock in vgic_irq_cmp().
Fix it by returning early when irqa == irqb.
Cc: stable@vger.kernel.org # 4.7+
Fixes: 8e4447457965 ("KVM: arm/arm64: vgic-new: Add IRQ sorting")
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Heyi Guo <guoheyi@huawei.com>
[maz: massaged commit log and patch, added Fixes and Cc-stable]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
virt/kvm/arm/vgic/vgic.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
index 6440b56ec90e2..1934dc8a2ce09 100644
--- a/virt/kvm/arm/vgic/vgic.c
+++ b/virt/kvm/arm/vgic/vgic.c
@@ -196,6 +196,13 @@ static int vgic_irq_cmp(void *priv, struct list_head *a, struct list_head *b)
bool penda, pendb;
int ret;
+ /*
+ * list_sort may call this function with the same element when
+ * the list is fairly long.
+ */
+ if (unlikely(irqa == irqb))
+ return 0;
+
spin_lock(&irqa->irq_lock);
spin_lock_nested(&irqb->irq_lock, SINGLE_DEPTH_NESTING);
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 81/83] KVM: arm/arm64: vgic-v2: Handle SGI bits in GICD_I{S,C}PENDR0 as WI
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (79 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 80/83] KVM: arm/arm64: vgic: Fix potential deadlock when ap_list is long Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 82/83] i2c: piix4: Fix port selection for AMD Family 16h Model 30h Greg Kroah-Hartman
` (7 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andre Przywara, Marc Zyngier,
Will Deacon, Sasha Levin
[ Upstream commit 82e40f558de566fdee214bec68096bbd5e64a6a4 ]
A guest is not allowed to inject a SGI (or clear its pending state)
by writing to GICD_ISPENDR0 (resp. GICD_ICPENDR0), as these bits are
defined as WI (as per ARM IHI 0048B 4.3.7 and 4.3.8).
Make sure we correctly emulate the architecture.
Fixes: 96b298000db4 ("KVM: arm/arm64: vgic-new: Add PENDING registers handlers")
Cc: stable@vger.kernel.org # 4.7+
Reported-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
virt/kvm/arm/vgic/vgic-mmio.c | 18 ++++++++++++++++++
virt/kvm/arm/vgic/vgic-v2.c | 5 ++++-
virt/kvm/arm/vgic/vgic-v3.c | 5 ++++-
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
index 85814d1bad11e..87742c9803a75 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.c
+++ b/virt/kvm/arm/vgic/vgic-mmio.c
@@ -120,6 +120,12 @@ unsigned long vgic_mmio_read_pending(struct kvm_vcpu *vcpu,
return value;
}
+static bool is_vgic_v2_sgi(struct kvm_vcpu *vcpu, struct vgic_irq *irq)
+{
+ return (vgic_irq_is_sgi(irq->intid) &&
+ vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V2);
+}
+
void vgic_mmio_write_spending(struct kvm_vcpu *vcpu,
gpa_t addr, unsigned int len,
unsigned long val)
@@ -130,6 +136,12 @@ void vgic_mmio_write_spending(struct kvm_vcpu *vcpu,
for_each_set_bit(i, &val, len * 8) {
struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
+ /* GICD_ISPENDR0 SGI bits are WI */
+ if (is_vgic_v2_sgi(vcpu, irq)) {
+ vgic_put_irq(vcpu->kvm, irq);
+ continue;
+ }
+
spin_lock(&irq->irq_lock);
irq->pending = true;
if (irq->config == VGIC_CONFIG_LEVEL)
@@ -150,6 +162,12 @@ void vgic_mmio_write_cpending(struct kvm_vcpu *vcpu,
for_each_set_bit(i, &val, len * 8) {
struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
+ /* GICD_ICPENDR0 SGI bits are WI */
+ if (is_vgic_v2_sgi(vcpu, irq)) {
+ vgic_put_irq(vcpu->kvm, irq);
+ continue;
+ }
+
spin_lock(&irq->irq_lock);
if (irq->config == VGIC_CONFIG_LEVEL) {
diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
index 1ab58f7b5d749..4c2919cc13ca6 100644
--- a/virt/kvm/arm/vgic/vgic-v2.c
+++ b/virt/kvm/arm/vgic/vgic-v2.c
@@ -154,7 +154,10 @@ void vgic_v2_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr)
if (vgic_irq_is_sgi(irq->intid)) {
u32 src = ffs(irq->source);
- BUG_ON(!src);
+ if (WARN_RATELIMIT(!src, "No SGI source for INTID %d\n",
+ irq->intid))
+ return;
+
val |= (src - 1) << GICH_LR_PHYSID_CPUID_SHIFT;
irq->source &= ~(1 << (src - 1));
if (irq->source)
diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
index c7924718990e5..267b1cf88a7fe 100644
--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/virt/kvm/arm/vgic/vgic-v3.c
@@ -137,7 +137,10 @@ void vgic_v3_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr)
model == KVM_DEV_TYPE_ARM_VGIC_V2) {
u32 src = ffs(irq->source);
- BUG_ON(!src);
+ if (WARN_RATELIMIT(!src, "No SGI source for INTID %d\n",
+ irq->intid))
+ return;
+
val |= (src - 1) << GICH_LR_PHYSID_CPUID_SHIFT;
irq->source &= ~(1 << (src - 1));
if (irq->source)
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 82/83] i2c: piix4: Fix port selection for AMD Family 16h Model 30h
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (80 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 81/83] KVM: arm/arm64: vgic-v2: Handle SGI bits in GICD_I{S,C}PENDR0 as WI Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-04 17:54 ` [PATCH 4.9 83/83] x86/ptrace: fix up botched merge of spectrev1 fix Greg Kroah-Hartman
` (6 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andrew Cooks, Jean Delvare,
Wolfram Sang, Sasha Levin
[ Upstream commit c7c06a1532f3fe106687ac82a13492c6a619ff1c ]
Family 16h Model 30h SMBus controller needs the same port selection fix
as described and fixed in commit 0fe16195f891 ("i2c: piix4: Fix SMBus port
selection for AMD Family 17h chips")
commit 6befa3fde65f ("i2c: piix4: Support alternative port selection
register") also fixed the port selection for Hudson2, but unfortunately
this is not the exact same device and the AMD naming and PCI Device IDs
aren't particularly helpful here.
The SMBus port selection register is common to the following Families
and models, as documented in AMD's publicly available BIOS and Kernel
Developer Guides:
50742 - Family 15h Model 60h-6Fh (PCI_DEVICE_ID_AMD_KERNCZ_SMBUS)
55072 - Family 15h Model 70h-7Fh (PCI_DEVICE_ID_AMD_KERNCZ_SMBUS)
52740 - Family 16h Model 30h-3Fh (PCI_DEVICE_ID_AMD_HUDSON2_SMBUS)
The Hudson2 PCI Device ID (PCI_DEVICE_ID_AMD_HUDSON2_SMBUS) is shared
between Bolton FCH and Family 16h Model 30h, but the location of the
SmBus0Sel port selection bits are different:
51192 - Bolton Register Reference Guide
We distinguish between Bolton and Family 16h Model 30h using the PCI
Revision ID:
Bolton is device 0x780b, revision 0x15
Family 16h Model 30h is device 0x780b, revision 0x1F
Family 15h Model 60h and 70h are both device 0x790b, revision 0x4A.
The following additional public AMD BKDG documents were checked and do
not share the same port selection register:
42301 - Family 15h Model 00h-0Fh doesn't mention any
42300 - Family 15h Model 10h-1Fh doesn't mention any
49125 - Family 15h Model 30h-3Fh doesn't mention any
48751 - Family 16h Model 00h-0Fh uses the previously supported
index register SB800_PIIX4_PORT_IDX_ALT at 0x2e
Signed-off-by: Andrew Cooks <andrew.cooks@opengear.com>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: stable@vger.kernel.org [v4.6+]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/i2c/busses/i2c-piix4.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index 8f1c5f24c1df5..62785aa76b3fb 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -96,7 +96,7 @@
#define SB800_PIIX4_PORT_IDX_MASK 0x06
#define SB800_PIIX4_PORT_IDX_SHIFT 1
-/* On kerncz, SmBus0Sel is at bit 20:19 of PMx00 DecodeEn */
+/* On kerncz and Hudson2, SmBus0Sel is at bit 20:19 of PMx00 DecodeEn */
#define SB800_PIIX4_PORT_IDX_KERNCZ 0x02
#define SB800_PIIX4_PORT_IDX_MASK_KERNCZ 0x18
#define SB800_PIIX4_PORT_IDX_SHIFT_KERNCZ 3
@@ -355,18 +355,16 @@ static int piix4_setup_sb800(struct pci_dev *PIIX4_dev,
/* Find which register is used for port selection */
if (PIIX4_dev->vendor == PCI_VENDOR_ID_AMD) {
- switch (PIIX4_dev->device) {
- case PCI_DEVICE_ID_AMD_KERNCZ_SMBUS:
+ if (PIIX4_dev->device == PCI_DEVICE_ID_AMD_KERNCZ_SMBUS ||
+ (PIIX4_dev->device == PCI_DEVICE_ID_AMD_HUDSON2_SMBUS &&
+ PIIX4_dev->revision >= 0x1F)) {
piix4_port_sel_sb800 = SB800_PIIX4_PORT_IDX_KERNCZ;
piix4_port_mask_sb800 = SB800_PIIX4_PORT_IDX_MASK_KERNCZ;
piix4_port_shift_sb800 = SB800_PIIX4_PORT_IDX_SHIFT_KERNCZ;
- break;
- case PCI_DEVICE_ID_AMD_HUDSON2_SMBUS:
- default:
+ } else {
piix4_port_sel_sb800 = SB800_PIIX4_PORT_IDX_ALT;
piix4_port_mask_sb800 = SB800_PIIX4_PORT_IDX_MASK;
piix4_port_shift_sb800 = SB800_PIIX4_PORT_IDX_SHIFT;
- break;
}
} else {
mutex_lock(&piix4_mutex_sb800);
--
2.20.1
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH 4.9 83/83] x86/ptrace: fix up botched merge of spectrev1 fix
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (81 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 82/83] i2c: piix4: Fix port selection for AMD Family 16h Model 30h Greg Kroah-Hartman
@ 2019-09-04 17:54 ` Greg Kroah-Hartman
2019-09-05 3:38 ` [PATCH 4.9 00/83] 4.9.191-stable review kernelci.org bot
` (5 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-04 17:54 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Brad Spengler, Dianzhang Chen,
Thomas Gleixner, bp, hpa
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I incorrectly merged commit 31a2fbb390fe ("x86/ptrace: Fix possible
spectre-v1 in ptrace_get_debugreg()") when backporting it, as was
graciously pointed out at
https://grsecurity.net/teardown_of_a_failed_linux_lts_spectre_fix.php
Resolve the upstream difference with the stable kernel merge to properly
protect things.
Reported-by: Brad Spengler <spender@grsecurity.net>
Cc: Dianzhang Chen <dianzhangchen0@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: <bp@alien8.de>
Cc: <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/ptrace.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -651,11 +651,10 @@ static unsigned long ptrace_get_debugreg
{
struct thread_struct *thread = &tsk->thread;
unsigned long val = 0;
- int index = n;
if (n < HBP_NUM) {
+ int index = array_index_nospec(n, HBP_NUM);
struct perf_event *bp = thread->ptrace_bps[index];
- index = array_index_nospec(index, HBP_NUM);
if (bp)
val = bp->hw.info.address;
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [PATCH 4.9 00/83] 4.9.191-stable review
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (82 preceding siblings ...)
2019-09-04 17:54 ` [PATCH 4.9 83/83] x86/ptrace: fix up botched merge of spectrev1 fix Greg Kroah-Hartman
@ 2019-09-05 3:38 ` kernelci.org bot
2019-09-05 14:33 ` shuah
` (4 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: kernelci.org bot @ 2019-09-05 3:38 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: Greg Kroah-Hartman, torvalds, akpm, linux, shuah, patches,
ben.hutchings, lkft-triage, stable
stable-rc/linux-4.9.y boot: 129 boots: 6 failed, 114 passed with 8 offline, 1 untried/unknown (v4.9.190-84-ga232f5b3e312)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.190-84-ga232f5b3e312/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.190-84-ga232f5b3e312/
Tree: stable-rc
Branch: linux-4.9.y
Git Describe: v4.9.190-84-ga232f5b3e312
Git Commit: a232f5b3e31224799f7506f9e9d4257d3d357d1b
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 57 unique boards, 22 SoC families, 15 builds out of 197
Boot Failures Detected:
arm:
multi_v7_defconfig:
gcc-8:
stih410-b2120: 1 failed lab
vexpress_defconfig:
gcc-8:
qemu_arm-virt-gicv3: 5 failed labs
Offline Platforms:
arm64:
defconfig:
gcc-8
apq8016-sbc: 1 offline lab
arm:
multi_v7_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
qcom-apq8064-ifc6410: 1 offline lab
sun5i-r8-chip: 1 offline lab
davinci_all_defconfig:
gcc-8
dm365evm,legacy: 1 offline lab
qcom_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
qcom-apq8064-ifc6410: 1 offline lab
sunxi_defconfig:
gcc-8
sun5i-r8-chip: 1 offline lab
---
For more info write to <info@kernelci.org>
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [PATCH 4.9 00/83] 4.9.191-stable review
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (83 preceding siblings ...)
2019-09-05 3:38 ` [PATCH 4.9 00/83] 4.9.191-stable review kernelci.org bot
@ 2019-09-05 14:33 ` shuah
2019-09-05 16:55 ` Guenter Roeck
` (3 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: shuah @ 2019-09-05 14:33 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, lkft-triage,
stable, shuah
On 9/4/19 11:52 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.191 release.
> There are 83 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri 06 Sep 2019 05:50:23 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.191-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [PATCH 4.9 00/83] 4.9.191-stable review
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (84 preceding siblings ...)
2019-09-05 14:33 ` shuah
@ 2019-09-05 16:55 ` Guenter Roeck
2019-09-05 17:26 ` Daniel Díaz
` (2 subsequent siblings)
88 siblings, 0 replies; 94+ messages in thread
From: Guenter Roeck @ 2019-09-05 16:55 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
On Wed, Sep 04, 2019 at 07:52:52PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.191 release.
> There are 83 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri 06 Sep 2019 05:50:23 PM UTC.
> Anything received after that time might be too late.
>
Build results:
total: 172 pass: 172 fail: 0
Qemu test results:
total: 356 pass: 356 fail: 0
Guenter
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [PATCH 4.9 00/83] 4.9.191-stable review
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (85 preceding siblings ...)
2019-09-05 16:55 ` Guenter Roeck
@ 2019-09-05 17:26 ` Daniel Díaz
2019-09-05 19:53 ` Kelsey Skunberg
2019-09-06 7:36 ` Jon Hunter
88 siblings, 0 replies; 94+ messages in thread
From: Daniel Díaz @ 2019-09-05 17:26 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, ben.hutchings,
lkft-triage, stable
Hello!
On 9/4/19 12:52 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.191 release.
> There are 83 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri 06 Sep 2019 05:50:23 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.191-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 4.9.191-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: a232f5b3e31224799f7506f9e9d4257d3d357d1b
git describe: v4.9.190-84-ga232f5b3e312
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.190-84-ga232f5b3e312
No regressions (compared to build v4.9.190)
No fixes (compared to build v4.9.190)
Ran 23512 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* network-basic-tests
* ltp-open-posix-tests
* prep-tmp-disk
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* ssuite
Greetings!
Daniel Díaz
daniel.diaz@linaro.org
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [PATCH 4.9 00/83] 4.9.191-stable review
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (86 preceding siblings ...)
2019-09-05 17:26 ` Daniel Díaz
@ 2019-09-05 19:53 ` Kelsey Skunberg
2019-09-06 7:36 ` Jon Hunter
88 siblings, 0 replies; 94+ messages in thread
From: Kelsey Skunberg @ 2019-09-05 19:53 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches,
ben.hutchings, lkft-triage, stable
On Wed, Sep 04, 2019 at 07:52:52PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.191 release.
> There are 83 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri 06 Sep 2019 05:50:23 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.191-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Compiled, booted, and no regressions on my system.
-Kelsey
^ permalink raw reply [flat|nested] 94+ messages in thread* Re: [PATCH 4.9 00/83] 4.9.191-stable review
2019-09-04 17:52 [PATCH 4.9 00/83] 4.9.191-stable review Greg Kroah-Hartman
` (87 preceding siblings ...)
2019-09-05 19:53 ` Kelsey Skunberg
@ 2019-09-06 7:36 ` Jon Hunter
88 siblings, 0 replies; 94+ messages in thread
From: Jon Hunter @ 2019-09-06 7:36 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, ben.hutchings,
lkft-triage, stable, linux-tegra
On 04/09/2019 18:52, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.191 release.
> There are 83 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri 06 Sep 2019 05:50:23 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.191-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v4.9:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
24 tests: 24 pass, 0 fail
Linux version: 4.9.191-rc1-ga232f5b3e312
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 94+ messages in thread