2020-04-20 12:53:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 00/40] 4.19.117-rc1 review

This is the start of the stable review cycle for the 4.19.117 release.
There are 40 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 Wed, 22 Apr 2020 12:10:36 +0000.
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.19.117-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.19.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 4.19.117-rc1

Austin Kim <[email protected]>
mm/vmalloc.c: move 'area->pages' after if statement

Karthick Gopalasubramanian <[email protected]>
wil6210: remove reset file from debugfs

Dedy Lansky <[email protected]>
wil6210: make sure Rx ring sizes are correlated

Alexei Avshalom Lazar <[email protected]>
wil6210: add general initialization/size checks

Maya Erez <[email protected]>
wil6210: ignore HALP ICR if already handled

Dedy Lansky <[email protected]>
wil6210: check rx_buff_mgmt before accessing it

Reinette Chatre <[email protected]>
x86/resctrl: Fix invalid attempt at removing the default resource group

James Morse <[email protected]>
x86/resctrl: Preserve CDP enable over CPU hotplug

John Allen <[email protected]>
x86/microcode/AMD: Increase microcode PATCH_MAX_SIZE

Maurizio Lombardi <[email protected]>
scsi: target: fix hang when multiple threads try to destroy the same iscsi session

Maurizio Lombardi <[email protected]>
scsi: target: remove boilerplate code

Jim Mattson <[email protected]>
kvm: x86: Host feature SSBD doesn't imply guest feature SPEC_CTRL_SSBD

Jan Kara <[email protected]>
ext4: do not zeroout extents beyond i_disksize

Sergei Lopatin <[email protected]>
drm/amd/powerplay: force the trim of the mclk dpm_levels if OD is enabled

Thinh Nguyen <[email protected]>
usb: dwc3: gadget: Don't clear flags before transfer ended

Sasha Levin <[email protected]>
usb: dwc3: gadget: don't enable interrupt when disabling endpoint

Tuomas Tynkkynen <[email protected]>
mac80211_hwsim: Use kstrndup() in place of kasprintf()

Josef Bacik <[email protected]>
btrfs: check commit root generation in should_ignore_root

Xiao Yang <[email protected]>
tracing: Fix the race between registering 'snapshot' event trigger and triggering 'snapshot' operation

Vasily Averin <[email protected]>
keys: Fix proc_keys_next to increase position index

Takashi Iwai <[email protected]>
ALSA: usb-audio: Check mapping at creating connector controls, too

Takashi Iwai <[email protected]>
ALSA: usb-audio: Don't create jack controls for PCM terminals

Takashi Iwai <[email protected]>
ALSA: usb-audio: Don't override ignore_ctl_error value from the map

Takashi Iwai <[email protected]>
ALSA: usb-audio: Filter error from connector kctl ops, too

Colin Ian King <[email protected]>
ASoC: Intel: mrfld: return error codes when an error occurs

Colin Ian King <[email protected]>
ASoC: Intel: mrfld: fix incorrect check on p->sink

Josh Triplett <[email protected]>
ext4: fix incorrect inodes per group in error message

Josh Triplett <[email protected]>
ext4: fix incorrect group count in ext4_fill_super error message

Sven Van Asbroeck <[email protected]>
pwm: pca9685: Fix PWM/GPIO inter-operation

zhangyi (F) <[email protected]>
jbd2: improve comments about freeing data buffers whose page mapping is NULL

Can Guo <[email protected]>
scsi: ufs: Fix ufshcd_hold() caused scheduling while atomic

Amir Goldstein <[email protected]>
ovl: fix value of i_ino for lower hardlink corner case

DENG Qingfang <[email protected]>
net: dsa: mt7530: fix tagged frames pass-through in VLAN-unaware mode

Florian Fainelli <[email protected]>
net: stmmac: dwmac-sunxi: Provide TX and RX fifo sizes

Konstantin Khlebnikov <[email protected]>
net: revert default NAPI poll timeout to 2 jiffies

Wang Wenhu <[email protected]>
net: qrtr: send msgs from local of same id as broadcast

Tim Stallard <[email protected]>
net: ipv6: do not consider routes via gateways for anycast address check

Taras Chornyi <[email protected]>
net: ipv4: devinet: Fix crash when add/del multicast IP with autojoin

Taehee Yoo <[email protected]>
hsr: check protocol version in hsr_newlink()

Sebastian Andrzej Siewior <[email protected]>
amd-xgbe: Use __napi_schedule() in BH context


-------------

Diffstat:

Makefile | 4 +-
arch/x86/include/asm/microcode_amd.h | 2 +-
arch/x86/kernel/cpu/intel_rdt.c | 2 +
arch/x86/kernel/cpu/intel_rdt.h | 1 +
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 16 ++++-
arch/x86/kvm/cpuid.c | 3 +-
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 5 +-
drivers/net/dsa/mt7530.c | 18 +++--
drivers/net/dsa/mt7530.h | 7 ++
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 2 +
drivers/net/wireless/ath/wil6210/debugfs.c | 29 +-------
drivers/net/wireless/ath/wil6210/interrupt.c | 12 ++--
drivers/net/wireless/ath/wil6210/main.c | 5 +-
drivers/net/wireless/ath/wil6210/txrx.c | 4 +-
drivers/net/wireless/ath/wil6210/txrx_edma.c | 14 +++-
drivers/net/wireless/ath/wil6210/wil6210.h | 3 +-
drivers/net/wireless/ath/wil6210/wmi.c | 2 +-
drivers/net/wireless/mac80211_hwsim.c | 12 ++--
drivers/pwm/pwm-pca9685.c | 85 +++++++++++++----------
drivers/scsi/ufs/ufshcd.c | 5 ++
drivers/target/iscsi/iscsi_target.c | 79 ++++++---------------
drivers/target/iscsi/iscsi_target.h | 1 -
drivers/target/iscsi/iscsi_target_configfs.c | 5 +-
drivers/target/iscsi/iscsi_target_login.c | 5 +-
drivers/usb/dwc3/gadget.c | 18 ++---
fs/btrfs/relocation.c | 4 +-
fs/ext4/extents.c | 8 +--
fs/ext4/super.c | 6 +-
fs/jbd2/commit.c | 7 +-
fs/overlayfs/inode.c | 4 +-
include/net/ip6_route.h | 1 +
include/target/iscsi/iscsi_target_core.h | 2 +-
kernel/trace/trace_events_trigger.c | 10 +--
mm/vmalloc.c | 8 ++-
net/core/dev.c | 3 +-
net/hsr/hsr_netlink.c | 10 ++-
net/ipv4/devinet.c | 13 ++--
net/qrtr/qrtr.c | 7 +-
security/keys/proc.c | 2 +
sound/soc/intel/atom/sst-atom-controls.c | 2 +-
sound/soc/intel/atom/sst/sst_pci.c | 2 +-
sound/usb/mixer.c | 31 +++++----
sound/usb/mixer_maps.c | 4 +-
44 files changed, 252 insertions(+), 213 deletions(-)



2020-04-20 12:53:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 08/40] net: dsa: mt7530: fix tagged frames pass-through in VLAN-unaware mode

From: DENG Qingfang <[email protected]>

[ Upstream commit e045124e93995fe01e42ed530003ddba5d55db4f ]

In VLAN-unaware mode, the Egress Tag (EG_TAG) field in Port VLAN
Control register must be set to Consistent to let tagged frames pass
through as is, otherwise their tags will be stripped.

Fixes: 83163f7dca56 ("net: dsa: mediatek: add VLAN support for MT7530")
Signed-off-by: DENG Qingfang <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Tested-by: René van Dorst <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/dsa/mt7530.c | 18 ++++++++++++------
drivers/net/dsa/mt7530.h | 7 +++++++
2 files changed, 19 insertions(+), 6 deletions(-)

--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -824,8 +824,9 @@ mt7530_port_set_vlan_unaware(struct dsa_
*/
mt7530_rmw(priv, MT7530_PCR_P(port), PCR_PORT_VLAN_MASK,
MT7530_PORT_MATRIX_MODE);
- mt7530_rmw(priv, MT7530_PVC_P(port), VLAN_ATTR_MASK,
- VLAN_ATTR(MT7530_VLAN_TRANSPARENT));
+ mt7530_rmw(priv, MT7530_PVC_P(port), VLAN_ATTR_MASK | PVC_EG_TAG_MASK,
+ VLAN_ATTR(MT7530_VLAN_TRANSPARENT) |
+ PVC_EG_TAG(MT7530_VLAN_EG_CONSISTENT));

priv->ports[port].vlan_filtering = false;

@@ -843,8 +844,8 @@ mt7530_port_set_vlan_unaware(struct dsa_
if (all_user_ports_removed) {
mt7530_write(priv, MT7530_PCR_P(MT7530_CPU_PORT),
PCR_MATRIX(dsa_user_ports(priv->ds)));
- mt7530_write(priv, MT7530_PVC_P(MT7530_CPU_PORT),
- PORT_SPEC_TAG);
+ mt7530_write(priv, MT7530_PVC_P(MT7530_CPU_PORT), PORT_SPEC_TAG
+ | PVC_EG_TAG(MT7530_VLAN_EG_CONSISTENT));
}
}

@@ -870,8 +871,9 @@ mt7530_port_set_vlan_aware(struct dsa_sw
/* Set the port as a user port which is to be able to recognize VID
* from incoming packets before fetching entry within the VLAN table.
*/
- mt7530_rmw(priv, MT7530_PVC_P(port), VLAN_ATTR_MASK,
- VLAN_ATTR(MT7530_VLAN_USER));
+ mt7530_rmw(priv, MT7530_PVC_P(port), VLAN_ATTR_MASK | PVC_EG_TAG_MASK,
+ VLAN_ATTR(MT7530_VLAN_USER) |
+ PVC_EG_TAG(MT7530_VLAN_EG_DISABLED));
}

static void
@@ -1297,6 +1299,10 @@ mt7530_setup(struct dsa_switch *ds)
mt7530_cpu_port_enable(priv, i);
else
mt7530_port_disable(ds, i, NULL);
+
+ /* Enable consistent egress tag */
+ mt7530_rmw(priv, MT7530_PVC_P(i), PVC_EG_TAG_MASK,
+ PVC_EG_TAG(MT7530_VLAN_EG_CONSISTENT));
}

/* Flush the FDB table */
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -167,9 +167,16 @@ enum mt7530_port_mode {
/* Register for port vlan control */
#define MT7530_PVC_P(x) (0x2010 + ((x) * 0x100))
#define PORT_SPEC_TAG BIT(5)
+#define PVC_EG_TAG(x) (((x) & 0x7) << 8)
+#define PVC_EG_TAG_MASK PVC_EG_TAG(7)
#define VLAN_ATTR(x) (((x) & 0x3) << 6)
#define VLAN_ATTR_MASK VLAN_ATTR(3)

+enum mt7530_vlan_port_eg_tag {
+ MT7530_VLAN_EG_DISABLED = 0,
+ MT7530_VLAN_EG_CONSISTENT = 1,
+};
+
enum mt7530_vlan_port_attr {
MT7530_VLAN_USER = 0,
MT7530_VLAN_TRANSPARENT = 3,


2020-04-20 12:54:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 19/40] ALSA: usb-audio: Dont create jack controls for PCM terminals

From: Takashi Iwai <[email protected]>

commit 7dc3c5a0172e6c0449502103356c3628d05bc0e0 upstream.

Some funky firmwares set the connector flag even on PCM terminals
although it doesn't make sense (and even actually the firmware doesn't
react properly!). Let's skip creation of jack controls in such a
case.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/usb/mixer.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)

--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -2107,7 +2107,8 @@ static int parse_audio_input_terminal(st
check_input_term(state, term_id, &iterm);

/* Check for jack detection. */
- if (uac_v2v3_control_is_readable(bmctls, control))
+ if ((iterm.type & 0xff00) != 0x0100 &&
+ uac_v2v3_control_is_readable(bmctls, control))
build_connector_control(state->mixer, &iterm, true);

return 0;
@@ -3147,7 +3148,8 @@ static int snd_usb_mixer_controls(struct
if (err < 0 && err != -EINVAL)
return err;

- if (uac_v2v3_control_is_readable(le16_to_cpu(desc->bmControls),
+ if ((state.oterm.type & 0xff00) != 0x0100 &&
+ uac_v2v3_control_is_readable(le16_to_cpu(desc->bmControls),
UAC2_TE_CONNECTOR)) {
build_connector_control(state.mixer, &state.oterm,
false);
@@ -3172,7 +3174,8 @@ static int snd_usb_mixer_controls(struct
if (err < 0 && err != -EINVAL)
return err;

- if (uac_v2v3_control_is_readable(le32_to_cpu(desc->bmControls),
+ if ((state.oterm.type & 0xff00) != 0x0100 &&
+ uac_v2v3_control_is_readable(le32_to_cpu(desc->bmControls),
UAC3_TE_INSERTION)) {
build_connector_control(state.mixer, &state.oterm,
false);


2020-04-20 12:54:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 15/40] ASoC: Intel: mrfld: fix incorrect check on p->sink

From: Colin Ian King <[email protected]>

commit f5e056e1e46fcbb5f74ce560792aeb7d57ce79e6 upstream.

The check on p->sink looks bogus, I believe it should be p->source
since the following code blocks are related to p->source. Fix
this by replacing p->sink with p->source.

Fixes: 24c8d14192cc ("ASoC: Intel: mrfld: add DSP core controls")
Signed-off-by: Colin Ian King <[email protected]>
Addresses-Coverity: ("Copy-paste error")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/soc/intel/atom/sst-atom-controls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/intel/atom/sst-atom-controls.c
+++ b/sound/soc/intel/atom/sst-atom-controls.c
@@ -1341,7 +1341,7 @@ int sst_send_pipe_gains(struct snd_soc_d
dai->capture_widget->name);
w = dai->capture_widget;
snd_soc_dapm_widget_for_each_source_path(w, p) {
- if (p->connected && !p->connected(w, p->sink))
+ if (p->connected && !p->connected(w, p->source))
continue;

if (p->connect && p->source->power &&


2020-04-20 12:54:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 14/40] ext4: fix incorrect inodes per group in error message

From: Josh Triplett <[email protected]>

commit b9c538da4e52a7b79dfcf4cfa487c46125066dfb upstream.

If ext4_fill_super detects an invalid number of inodes per group, the
resulting error message printed the number of blocks per group, rather
than the number of inodes per group. Fix it to print the correct value.

Fixes: cd6bb35bf7f6d ("ext4: use more strict checks for inodes_per_block on mount")
Link: https://lore.kernel.org/r/8be03355983a08e5d4eed480944613454d7e2550.1585434649.git.josh@joshtriplett.org
Reviewed-by: Andreas Dilger <[email protected]>
Signed-off-by: Josh Triplett <[email protected]>
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext4/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4031,7 +4031,7 @@ static int ext4_fill_super(struct super_
if (sbi->s_inodes_per_group < sbi->s_inodes_per_block ||
sbi->s_inodes_per_group > blocksize * 8) {
ext4_msg(sb, KERN_ERR, "invalid inodes per group: %lu\n",
- sbi->s_blocks_per_group);
+ sbi->s_inodes_per_group);
goto failed_mount;
}
sbi->s_itb_per_group = sbi->s_inodes_per_group /


2020-04-20 12:54:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 34/40] x86/resctrl: Fix invalid attempt at removing the default resource group

From: Reinette Chatre <[email protected]>

commit b0151da52a6d4f3951ea24c083e7a95977621436 upstream.

The default resource group ("rdtgroup_default") is associated with the
root of the resctrl filesystem and should never be removed. New resource
groups can be created as subdirectories of the resctrl filesystem and
they can be removed from user space.

There exists a safeguard in the directory removal code
(rdtgroup_rmdir()) that ensures that only subdirectories can be removed
by testing that the directory to be removed has to be a child of the
root directory.

A possible deadlock was recently fixed with

334b0f4e9b1b ("x86/resctrl: Fix a deadlock due to inaccurate reference").

This fix involved associating the private data of the "mon_groups"
and "mon_data" directories to the resource group to which they belong
instead of NULL as before. A consequence of this change was that
the original safeguard code preventing removal of "mon_groups" and
"mon_data" found in the root directory failed resulting in attempts to
remove the default resource group that ends in a BUG:

kernel BUG at mm/slub.c:3969!
invalid opcode: 0000 [#1] SMP PTI

Call Trace:
rdtgroup_rmdir+0x16b/0x2c0
kernfs_iop_rmdir+0x5c/0x90
vfs_rmdir+0x7a/0x160
do_rmdir+0x17d/0x1e0
do_syscall_64+0x55/0x1d0
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fix this by improving the directory removal safeguard to ensure that
subdirectories of the resctrl root directory can only be removed if they
are a child of the resctrl filesystem's root _and_ not associated with
the default resource group.

Fixes: 334b0f4e9b1b ("x86/resctrl: Fix a deadlock due to inaccurate reference")
Reported-by: Sai Praneeth Prakhya <[email protected]>
Signed-off-by: Reinette Chatre <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Tested-by: Sai Praneeth Prakhya <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/884cbe1773496b5dbec1b6bd11bb50cffa83603d.1584461853.git.reinette.chatre@intel.com
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@ -2923,7 +2923,8 @@ static int rdtgroup_rmdir(struct kernfs_
* If the rdtgroup is a mon group and parent directory
* is a valid "mon_groups" directory, remove the mon group.
*/
- if (rdtgrp->type == RDTCTRL_GROUP && parent_kn == rdtgroup_default.kn) {
+ if (rdtgrp->type == RDTCTRL_GROUP && parent_kn == rdtgroup_default.kn &&
+ rdtgrp != &rdtgroup_default) {
if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP ||
rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED) {
ret = rdtgroup_ctrl_remove(kn, rdtgrp);


2020-04-20 12:55:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 05/40] net: qrtr: send msgs from local of same id as broadcast

From: Wang Wenhu <[email protected]>

[ Upstream commit 6dbf02acef69b0742c238574583b3068afbd227c ]

If the local node id(qrtr_local_nid) is not modified after its
initialization, it equals to the broadcast node id(QRTR_NODE_BCAST).
So the messages from local node should not be taken as broadcast
and keep the process going to send them out anyway.

The definitions are as follow:
static unsigned int qrtr_local_nid = NUMA_NO_NODE;

Fixes: fdf5fd397566 ("net: qrtr: Broadcast messages only from control port")
Signed-off-by: Wang Wenhu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/qrtr/qrtr.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

--- a/net/qrtr/qrtr.c
+++ b/net/qrtr/qrtr.c
@@ -769,20 +769,21 @@ static int qrtr_sendmsg(struct socket *s

node = NULL;
if (addr->sq_node == QRTR_NODE_BCAST) {
- enqueue_fn = qrtr_bcast_enqueue;
- if (addr->sq_port != QRTR_PORT_CTRL) {
+ if (addr->sq_port != QRTR_PORT_CTRL &&
+ qrtr_local_nid != QRTR_NODE_BCAST) {
release_sock(sk);
return -ENOTCONN;
}
+ enqueue_fn = qrtr_bcast_enqueue;
} else if (addr->sq_node == ipc->us.sq_node) {
enqueue_fn = qrtr_local_enqueue;
} else {
- enqueue_fn = qrtr_node_enqueue;
node = qrtr_node_lookup(addr->sq_node);
if (!node) {
release_sock(sk);
return -ECONNRESET;
}
+ enqueue_fn = qrtr_node_enqueue;
}

plen = (len + 3) & ~3;


2020-04-20 16:33:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 37/40] wil6210: add general initialization/size checks

From: Alexei Avshalom Lazar <[email protected]>

commit ac0e541ab2f2951845acee784ef487be40fb4c77 upstream.

Initialize unset variable, and verify that mid is valid.

Signed-off-by: Alexei Avshalom Lazar <[email protected]>
Signed-off-by: Maya Erez <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/wil6210/debugfs.c | 2 ++
drivers/net/wireless/ath/wil6210/wmi.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -991,6 +991,8 @@ static ssize_t wil_write_file_txmgmt(str
int rc;
void *frame;

+ memset(&params, 0, sizeof(params));
+
if (!len)
return -EINVAL;

--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -2802,7 +2802,7 @@ static void wmi_event_handle(struct wil6

if (mid == MID_BROADCAST)
mid = 0;
- if (mid >= wil->max_vifs) {
+ if (mid >= ARRAY_SIZE(wil->vifs) || mid >= wil->max_vifs) {
wil_dbg_wmi(wil, "invalid mid %d, event skipped\n",
mid);
return;


2020-04-20 16:33:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 40/40] mm/vmalloc.c: move area->pages after if statement

From: Austin Kim <[email protected]>

commit 7ea362427c170061b8822dd41bafaa72b3bcb9ad upstream.

If !area->pages statement is true where memory allocation fails, area is
freed.

In this case 'area->pages = pages' should not executed. So move
'area->pages = pages' after if statement.

[[email protected]: give area->pages the same treatment]
Link: http://lkml.kernel.org/r/20190830035716.GA190684@LGEARND20B15
Signed-off-by: Austin Kim <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Cc: Uladzislau Rezki (Sony) <[email protected]>
Cc: Roman Gushchin <[email protected]>
Cc: Roman Penyaev <[email protected]>
Cc: Rick Edgecombe <[email protected]>
Cc: Mike Rapoport <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/vmalloc.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1668,7 +1668,6 @@ static void *__vmalloc_area_node(struct
nr_pages = get_vm_area_size(area) >> PAGE_SHIFT;
array_size = (nr_pages * sizeof(struct page *));

- area->nr_pages = nr_pages;
/* Please note that the recursion is strictly bounded. */
if (array_size > PAGE_SIZE) {
pages = __vmalloc_node(array_size, 1, nested_gfp|highmem_mask,
@@ -1676,13 +1675,16 @@ static void *__vmalloc_area_node(struct
} else {
pages = kmalloc_node(array_size, nested_gfp, node);
}
- area->pages = pages;
- if (!area->pages) {
+
+ if (!pages) {
remove_vm_area(area->addr);
kfree(area);
return NULL;
}

+ area->pages = pages;
+ area->nr_pages = nr_pages;
+
for (i = 0; i < area->nr_pages; i++) {
struct page *page;



2020-04-20 16:34:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 23/40] btrfs: check commit root generation in should_ignore_root

From: Josef Bacik <[email protected]>

commit 4d4225fc228e46948486d8b8207955f0c031b92e upstream.

Previously we would set the reloc root's last snapshot to transid - 1.
However there was a problem with doing this, and we changed it to
setting the last snapshot to the generation of the commit node of the fs
root.

This however broke should_ignore_root(). The assumption is that if we
are in a generation newer than when the reloc root was created, then we
would find the reloc root through normal backref lookups, and thus can
ignore any fs roots we find with an old enough reloc root.

Now that the last snapshot could be considerably further in the past
than before, we'd end up incorrectly ignoring an fs root. Thus we'd
find no nodes for the bytenr we were searching for, and we'd fail to
relocate anything. We'd loop through the relocate code again and see
that there were still used space in that block group, attempt to
relocate those bytenr's again, fail in the same way, and just loop like
this forever. This is tricky in that we have to not modify the fs root
at all during this time, so we need to have a block group that has data
in this fs root that is not shared by any other root, which is why this
has been difficult to reproduce.

Fixes: 054570a1dc94 ("Btrfs: fix relocation incorrectly dropping data references")
CC: [email protected] # 4.9+
Reviewed-by: Filipe Manana <[email protected]>
Signed-off-by: Josef Bacik <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/btrfs/relocation.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -525,8 +525,8 @@ static int should_ignore_root(struct btr
if (!reloc_root)
return 0;

- if (btrfs_root_last_snapshot(&reloc_root->root_item) ==
- root->fs_info->running_transaction->transid - 1)
+ if (btrfs_header_generation(reloc_root->commit_root) ==
+ root->fs_info->running_transaction->transid)
return 0;
/*
* if there is reloc tree and it was created in previous


2020-04-20 16:34:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 16/40] ASoC: Intel: mrfld: return error codes when an error occurs

From: Colin Ian King <[email protected]>

commit 3025571edd9df653e1ad649f0638368a39d1bbb5 upstream.

Currently function sst_platform_get_resources always returns zero and
error return codes set by the function are never returned. Fix this
by returning the error return code in variable ret rather than the
hard coded zero.

Addresses-Coverity: ("Unused value")
Fixes: f533a035e4da ("ASoC: Intel: mrfld - create separate module for pci part")
Signed-off-by: Colin Ian King <[email protected]>
Acked-by: Cezary Rojewski <[email protected]>
Acked-by: Pierre-Louis Bossart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/soc/intel/atom/sst/sst_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/intel/atom/sst/sst_pci.c
+++ b/sound/soc/intel/atom/sst/sst_pci.c
@@ -107,7 +107,7 @@ static int sst_platform_get_resources(st
dev_dbg(ctx->dev, "DRAM Ptr %p\n", ctx->dram);
do_release_regions:
pci_release_regions(pci);
- return 0;
+ return ret;
}

/*


2020-04-20 16:34:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 03/40] net: ipv4: devinet: Fix crash when add/del multicast IP with autojoin

From: Taras Chornyi <[email protected]>

[ Upstream commit 690cc86321eb9bcee371710252742fb16fe96824 ]

When CONFIG_IP_MULTICAST is not set and multicast ip is added to the device
with autojoin flag or when multicast ip is deleted kernel will crash.

steps to reproduce:

ip addr add 224.0.0.0/32 dev eth0
ip addr del 224.0.0.0/32 dev eth0

or

ip addr add 224.0.0.0/32 dev eth0 autojoin

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088
pc : _raw_write_lock_irqsave+0x1e0/0x2ac
lr : lock_sock_nested+0x1c/0x60
Call trace:
_raw_write_lock_irqsave+0x1e0/0x2ac
lock_sock_nested+0x1c/0x60
ip_mc_config.isra.28+0x50/0xe0
inet_rtm_deladdr+0x1a8/0x1f0
rtnetlink_rcv_msg+0x120/0x350
netlink_rcv_skb+0x58/0x120
rtnetlink_rcv+0x14/0x20
netlink_unicast+0x1b8/0x270
netlink_sendmsg+0x1a0/0x3b0
____sys_sendmsg+0x248/0x290
___sys_sendmsg+0x80/0xc0
__sys_sendmsg+0x68/0xc0
__arm64_sys_sendmsg+0x20/0x30
el0_svc_common.constprop.2+0x88/0x150
do_el0_svc+0x20/0x80
el0_sync_handler+0x118/0x190
el0_sync+0x140/0x180

Fixes: 93a714d6b53d ("multicast: Extend ip address command to enable multicast group join/leave on")
Signed-off-by: Taras Chornyi <[email protected]>
Signed-off-by: Vadym Kochan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/devinet.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)

--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -587,12 +587,15 @@ struct in_ifaddr *inet_ifa_byprefix(stru
return NULL;
}

-static int ip_mc_config(struct sock *sk, bool join, const struct in_ifaddr *ifa)
+static int ip_mc_autojoin_config(struct net *net, bool join,
+ const struct in_ifaddr *ifa)
{
+#if defined(CONFIG_IP_MULTICAST)
struct ip_mreqn mreq = {
.imr_multiaddr.s_addr = ifa->ifa_address,
.imr_ifindex = ifa->ifa_dev->dev->ifindex,
};
+ struct sock *sk = net->ipv4.mc_autojoin_sk;
int ret;

ASSERT_RTNL();
@@ -605,6 +608,9 @@ static int ip_mc_config(struct sock *sk,
release_sock(sk);

return ret;
+#else
+ return -EOPNOTSUPP;
+#endif
}

static int inet_rtm_deladdr(struct sk_buff *skb, struct nlmsghdr *nlh,
@@ -646,7 +652,7 @@ static int inet_rtm_deladdr(struct sk_bu
continue;

if (ipv4_is_multicast(ifa->ifa_address))
- ip_mc_config(net->ipv4.mc_autojoin_sk, false, ifa);
+ ip_mc_autojoin_config(net, false, ifa);
__inet_del_ifa(in_dev, ifap, 1, nlh, NETLINK_CB(skb).portid);
return 0;
}
@@ -907,8 +913,7 @@ static int inet_rtm_newaddr(struct sk_bu
*/
set_ifa_lifetime(ifa, valid_lft, prefered_lft);
if (ifa->ifa_flags & IFA_F_MCAUTOJOIN) {
- int ret = ip_mc_config(net->ipv4.mc_autojoin_sk,
- true, ifa);
+ int ret = ip_mc_autojoin_config(net, true, ifa);

if (ret < 0) {
inet_free_ifa(ifa);


2020-04-20 16:34:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 13/40] ext4: fix incorrect group count in ext4_fill_super error message

From: Josh Triplett <[email protected]>

commit df41460a21b06a76437af040d90ccee03888e8e5 upstream.

ext4_fill_super doublechecks the number of groups before mounting; if
that check fails, the resulting error message prints the group count
from the ext4_sb_info sbi, which hasn't been set yet. Print the freshly
computed group count instead (which at that point has just been computed
in "blocks_count").

Signed-off-by: Josh Triplett <[email protected]>
Fixes: 4ec1102813798 ("ext4: Add sanity checks for the superblock before mounting the filesystem")
Link: https://lore.kernel.org/r/8b957cd1513fcc4550fe675c10bcce2175c33a49.1585431964.git.josh@joshtriplett.org
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext4/super.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4162,9 +4162,9 @@ static int ext4_fill_super(struct super_
EXT4_BLOCKS_PER_GROUP(sb) - 1);
do_div(blocks_count, EXT4_BLOCKS_PER_GROUP(sb));
if (blocks_count > ((uint64_t)1<<32) - EXT4_DESC_PER_BLOCK(sb)) {
- ext4_msg(sb, KERN_WARNING, "groups count too large: %u "
+ ext4_msg(sb, KERN_WARNING, "groups count too large: %llu "
"(block count %llu, first data block %u, "
- "blocks per group %lu)", sbi->s_groups_count,
+ "blocks per group %lu)", blocks_count,
ext4_blocks_count(es),
le32_to_cpu(es->s_first_data_block),
EXT4_BLOCKS_PER_GROUP(sb));


2020-04-20 16:34:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 02/40] hsr: check protocol version in hsr_newlink()

From: Taehee Yoo <[email protected]>

[ Upstream commit 4faab8c446def7667adf1f722456c2f4c304069c ]

In the current hsr code, only 0 and 1 protocol versions are valid.
But current hsr code doesn't check the version, which is received by
userspace.

Test commands:
ip link add dummy0 type dummy
ip link add dummy1 type dummy
ip link add hsr0 type hsr slave1 dummy0 slave2 dummy1 version 4

In the test commands, version 4 is invalid.
So, the command should be failed.

After this patch, following error will occur.
"Error: hsr: Only versions 0..1 are supported."

Fixes: ee1c27977284 ("net/hsr: Added support for HSR v1")
Signed-off-by: Taehee Yoo <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/hsr/hsr_netlink.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

--- a/net/hsr/hsr_netlink.c
+++ b/net/hsr/hsr_netlink.c
@@ -64,10 +64,16 @@ static int hsr_newlink(struct net *src_n
else
multicast_spec = nla_get_u8(data[IFLA_HSR_MULTICAST_SPEC]);

- if (!data[IFLA_HSR_VERSION])
+ if (!data[IFLA_HSR_VERSION]) {
hsr_version = 0;
- else
+ } else {
hsr_version = nla_get_u8(data[IFLA_HSR_VERSION]);
+ if (hsr_version > 1) {
+ NL_SET_ERR_MSG_MOD(extack,
+ "Only versions 0..1 are supported");
+ return -EINVAL;
+ }
+ }

return hsr_dev_finalize(dev, link, multicast_spec, hsr_version);
}


2020-04-20 16:34:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 11/40] jbd2: improve comments about freeing data buffers whose page mapping is NULL

From: zhangyi (F) <[email protected]>

commit 780f66e59231fcf882f36c63f287252ee47cc75a upstream.

Improve comments in jbd2_journal_commit_transaction() to describe why
we don't need to clear the buffer_mapped bit for freeing file mapping
buffers whose page mapping is NULL.

Link: https://lore.kernel.org/r/[email protected]
Fixes: c96dceeabf76 ("jbd2: do not clear the BH_Mapped flag when forgetting a metadata buffer")
Suggested-by: Jan Kara <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Signed-off-by: zhangyi (F) <[email protected]>
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/jbd2/commit.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

--- a/fs/jbd2/commit.c
+++ b/fs/jbd2/commit.c
@@ -992,9 +992,10 @@ restart_loop:
* journalled data) we need to unmap buffer and clear
* more bits. We also need to be careful about the check
* because the data page mapping can get cleared under
- * out hands, which alse need not to clear more bits
- * because the page and buffers will be freed and can
- * never be reused once we are done with them.
+ * our hands. Note that if mapping == NULL, we don't
+ * need to make buffer unmapped because the page is
+ * already detached from the mapping and buffers cannot
+ * get reused.
*/
mapping = READ_ONCE(bh->b_page->mapping);
if (mapping && !sb_is_blkdev_sb(mapping->host->i_sb)) {


2020-04-20 16:34:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 10/40] scsi: ufs: Fix ufshcd_hold() caused scheduling while atomic

From: Can Guo <[email protected]>

commit c63d6099a7959ecc919b2549dc6b71f53521f819 upstream.

The async version of ufshcd_hold(async == true), which is only called in
queuecommand path as for now, is expected to work in atomic context, thus
it should not sleep or schedule out. When it runs into the condition that
clocks are ON but link is still in hibern8 state, it should bail out
without flushing the clock ungate work.

Fixes: f2a785ac2312 ("scsi: ufshcd: Fix race between clk scaling and ungate work")
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hongwu Su <[email protected]>
Reviewed-by: Asutosh Das <[email protected]>
Reviewed-by: Bean Huo <[email protected]>
Reviewed-by: Stanley Chu <[email protected]>
Signed-off-by: Can Guo <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/ufs/ufshcd.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1563,6 +1563,11 @@ start:
*/
if (ufshcd_can_hibern8_during_gating(hba) &&
ufshcd_is_link_hibern8(hba)) {
+ if (async) {
+ rc = -EAGAIN;
+ hba->clk_gating.active_reqs--;
+ break;
+ }
spin_unlock_irqrestore(hba->host->host_lock, flags);
flush_work(&hba->clk_gating.ungate_work);
spin_lock_irqsave(hba->host->host_lock, flags);


2020-04-20 16:40:50

by Chris Paterson

[permalink] [raw]
Subject: RE: [PATCH 4.19 00/40] 4.19.117-rc1 review

Hello Greg,

> From: [email protected] <[email protected]> On
> Behalf Of Greg Kroah-Hartman
> Sent: 20 April 2020 13:39
>
> This is the start of the stable review cycle for the 4.19.117 release.
> There are 40 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.

No build/boot issues seen for CIP configs for Linux 4.19.117-rc1 (df86600ce713).

Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/137867597
GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.19.y.yml
Relevant LAVA jobs: https://lava.ciplatform.org/scheduler/alljobs?length=25&search=df86600ce#table

Kind regards, Chris

>
> Responses should be made by Wed, 22 Apr 2020 12:10:36 +0000.
> 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.19.117-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.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman <[email protected]>
> Linux 4.19.117-rc1
>
> Austin Kim <[email protected]>
> mm/vmalloc.c: move 'area->pages' after if statement
>
> Karthick Gopalasubramanian <[email protected]>
> wil6210: remove reset file from debugfs
>
> Dedy Lansky <[email protected]>
> wil6210: make sure Rx ring sizes are correlated
>
> Alexei Avshalom Lazar <[email protected]>
> wil6210: add general initialization/size checks
>
> Maya Erez <[email protected]>
> wil6210: ignore HALP ICR if already handled
>
> Dedy Lansky <[email protected]>
> wil6210: check rx_buff_mgmt before accessing it
>
> Reinette Chatre <[email protected]>
> x86/resctrl: Fix invalid attempt at removing the default resource group
>
> James Morse <[email protected]>
> x86/resctrl: Preserve CDP enable over CPU hotplug
>
> John Allen <[email protected]>
> x86/microcode/AMD: Increase microcode PATCH_MAX_SIZE
>
> Maurizio Lombardi <[email protected]>
> scsi: target: fix hang when multiple threads try to destroy the same iscsi
> session
>
> Maurizio Lombardi <[email protected]>
> scsi: target: remove boilerplate code
>
> Jim Mattson <[email protected]>
> kvm: x86: Host feature SSBD doesn't imply guest feature SPEC_CTRL_SSBD
>
> Jan Kara <[email protected]>
> ext4: do not zeroout extents beyond i_disksize
>
> Sergei Lopatin <[email protected]>
> drm/amd/powerplay: force the trim of the mclk dpm_levels if OD is enabled
>
> Thinh Nguyen <[email protected]>
> usb: dwc3: gadget: Don't clear flags before transfer ended
>
> Sasha Levin <[email protected]>
> usb: dwc3: gadget: don't enable interrupt when disabling endpoint
>
> Tuomas Tynkkynen <[email protected]>
> mac80211_hwsim: Use kstrndup() in place of kasprintf()
>
> Josef Bacik <[email protected]>
> btrfs: check commit root generation in should_ignore_root
>
> Xiao Yang <[email protected]>
> tracing: Fix the race between registering 'snapshot' event trigger and
> triggering 'snapshot' operation
>
> Vasily Averin <[email protected]>
> keys: Fix proc_keys_next to increase position index
>
> Takashi Iwai <[email protected]>
> ALSA: usb-audio: Check mapping at creating connector controls, too
>
> Takashi Iwai <[email protected]>
> ALSA: usb-audio: Don't create jack controls for PCM terminals
>
> Takashi Iwai <[email protected]>
> ALSA: usb-audio: Don't override ignore_ctl_error value from the map
>
> Takashi Iwai <[email protected]>
> ALSA: usb-audio: Filter error from connector kctl ops, too
>
> Colin Ian King <[email protected]>
> ASoC: Intel: mrfld: return error codes when an error occurs
>
> Colin Ian King <[email protected]>
> ASoC: Intel: mrfld: fix incorrect check on p->sink
>
> Josh Triplett <[email protected]>
> ext4: fix incorrect inodes per group in error message
>
> Josh Triplett <[email protected]>
> ext4: fix incorrect group count in ext4_fill_super error message
>
> Sven Van Asbroeck <[email protected]>
> pwm: pca9685: Fix PWM/GPIO inter-operation
>
> zhangyi (F) <[email protected]>
> jbd2: improve comments about freeing data buffers whose page mapping is
> NULL
>
> Can Guo <[email protected]>
> scsi: ufs: Fix ufshcd_hold() caused scheduling while atomic
>
> Amir Goldstein <[email protected]>
> ovl: fix value of i_ino for lower hardlink corner case
>
> DENG Qingfang <[email protected]>
> net: dsa: mt7530: fix tagged frames pass-through in VLAN-unaware mode
>
> Florian Fainelli <[email protected]>
> net: stmmac: dwmac-sunxi: Provide TX and RX fifo sizes
>
> Konstantin Khlebnikov <[email protected]>
> net: revert default NAPI poll timeout to 2 jiffies
>
> Wang Wenhu <[email protected]>
> net: qrtr: send msgs from local of same id as broadcast
>
> Tim Stallard <[email protected]>
> net: ipv6: do not consider routes via gateways for anycast address check
>
> Taras Chornyi <[email protected]>
> net: ipv4: devinet: Fix crash when add/del multicast IP with autojoin
>
> Taehee Yoo <[email protected]>
> hsr: check protocol version in hsr_newlink()
>
> Sebastian Andrzej Siewior <[email protected]>
> amd-xgbe: Use __napi_schedule() in BH context
>
>
> -------------
>
> Diffstat:
>
> Makefile | 4 +-
> arch/x86/include/asm/microcode_amd.h | 2 +-
> arch/x86/kernel/cpu/intel_rdt.c | 2 +
> arch/x86/kernel/cpu/intel_rdt.h | 1 +
> arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 16 ++++-
> arch/x86/kvm/cpuid.c | 3 +-
> drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 5 +-
> drivers/net/dsa/mt7530.c | 18 +++--
> drivers/net/dsa/mt7530.h | 7 ++
> drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +-
> drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 2 +
> drivers/net/wireless/ath/wil6210/debugfs.c | 29 +-------
> drivers/net/wireless/ath/wil6210/interrupt.c | 12 ++--
> drivers/net/wireless/ath/wil6210/main.c | 5 +-
> drivers/net/wireless/ath/wil6210/txrx.c | 4 +-
> drivers/net/wireless/ath/wil6210/txrx_edma.c | 14 +++-
> drivers/net/wireless/ath/wil6210/wil6210.h | 3 +-
> drivers/net/wireless/ath/wil6210/wmi.c | 2 +-
> drivers/net/wireless/mac80211_hwsim.c | 12 ++--
> drivers/pwm/pwm-pca9685.c | 85 +++++++++++++----------
> drivers/scsi/ufs/ufshcd.c | 5 ++
> drivers/target/iscsi/iscsi_target.c | 79 ++++++---------------
> drivers/target/iscsi/iscsi_target.h | 1 -
> drivers/target/iscsi/iscsi_target_configfs.c | 5 +-
> drivers/target/iscsi/iscsi_target_login.c | 5 +-
> drivers/usb/dwc3/gadget.c | 18 ++---
> fs/btrfs/relocation.c | 4 +-
> fs/ext4/extents.c | 8 +--
> fs/ext4/super.c | 6 +-
> fs/jbd2/commit.c | 7 +-
> fs/overlayfs/inode.c | 4 +-
> include/net/ip6_route.h | 1 +
> include/target/iscsi/iscsi_target_core.h | 2 +-
> kernel/trace/trace_events_trigger.c | 10 +--
> mm/vmalloc.c | 8 ++-
> net/core/dev.c | 3 +-
> net/hsr/hsr_netlink.c | 10 ++-
> net/ipv4/devinet.c | 13 ++--
> net/qrtr/qrtr.c | 7 +-
> security/keys/proc.c | 2 +
> sound/soc/intel/atom/sst-atom-controls.c | 2 +-
> sound/soc/intel/atom/sst/sst_pci.c | 2 +-
> sound/usb/mixer.c | 31 +++++----
> sound/usb/mixer_maps.c | 4 +-
> 44 files changed, 252 insertions(+), 213 deletions(-)
>

2020-04-20 19:54:18

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/40] 4.19.117-rc1 review

On 4/20/20 5:39 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.117 release.
> There are 40 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 Wed, 22 Apr 2020 12:10:36 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 418 pass: 418 fail: 0

Guenter

2020-04-20 22:26:01

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/40] 4.19.117-rc1 review

On Mon, 20 Apr 2020 at 18:21, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.19.117 release.
> There are 40 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 Wed, 22 Apr 2020 12:10:36 +0000.
> 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.19.117-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.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


Results from Linaro’s test farm.
Regressions on x86_64.

x86_64 boot failed due to kernel BUG and kernel panic.
It is hard to reproduce this BUG and kernel panic
We are investigating this problem. The full log links are at [1] and [2].

[ 0.000000] Linux version 4.19.117-rc1+ (TuxBuild@f0f6d9b6cd32) (gcc
version 9.3.0 (Debian 9.3.0-8)) #1 SMP Mon Apr 20 12:40:09 UTC 2020
<>
[ 3.237717] igb 0000:01:00.0: Using MSI-X interrupts. 4 rx
queue(s), 4 tx queue(s)
[ 3.246412] BUG: unable to handle kernel paging request at 00000000482444ab
[ 3.246412] PGD 0 P4D 0
[ 3.246412] Oops: 0002 [#1] SMP PTI
[ 3.246412] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.19.117-rc1+ #1
[ 3.246412] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[ 3.246412] RIP: 0010:__hw_addr_add_ex+0xa/0xf0
[ 3.246412] Code: 10 01 49 89 5f 08 48 83 c4 08 5b 5d 41 5c 41 5d
41 5e 41 5f c3 b8 f4 ff ff ff eb ea 0f 1f 40 00 41 57 41 56 41 55 41
54 55 53 <48> 83 8c 10 8b 44 24 48 89 4c 24 08 44 89 04 24 44 89 4c 24
04 89
[ 3.246412] RSP: 0000:ffff9d614002fc48 EFLAGS: 00010246
[ 3.246412] RAX: 0000000000000000 RBX: ffff975d9c17c000 RCX: 0000000000000001
[ 3.246412] RDX: 0000000000000020 RSI: ffff9d614002fc88 RDI: ffff975d9c17c290
[ 3.246412] RBP: ffff975d9c17c000 R08: 0000000000000000 R09: 0000000000000000
[ 3.246412] R10: ffff975d9da8ee68 R11: 00000000ffffffff R12: 0000000000000008
[ 3.246412] R13: ffffffffab8ba5bc R14: 0000000000000000 R15: ffffffffaafc93d0
[ 3.246412] FS: 0000000000000000(0000) GS:ffff975d9fa80000(0000)
knlGS:0000000000000000
[ 3.246412] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.438798] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 3.246412] CR2: 00000000482444ab CR3: 0000000211c0a001 CR4: 00000000003606e0
[ 3.246412] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 3.246412] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 3.246412] Call Trace:
[ 3.246412] ? eth_header+0xb0/0xb0
[ 3.246412] dev_addr_init+0x76/0xb0
[ 3.448543] ata4: SATA link down (SStatus 0 SControl 300)
[ 3.246412] alloc_netdev_mqs+0x9d/0x3e0
[ 3.246412] igb_probe+0x16e/0x14d0
[ 3.462804] ata7: SATA link down (SStatus 0 SControl 300)
[ 3.246412] local_pci_probe+0x3e/0x90
[ 3.246412] pci_device_probe+0x102/0x1a0
[ 3.246412] really_probe+0x1be/0x260
[ 3.472410] ata5: SATA link down (SStatus 0 SControl 300)
[ 3.246412] driver_probe_device+0x4b/0x90
[ 3.246412] __driver_attach+0xbb/0xc0
[ 3.246412] ? driver_probe_device+0x90/0x90
[ 3.246412] bus_for_each_dev+0x73/0xb0
[ 3.246412] bus_add_driver+0x192/0x1d0
[ 3.246412] driver_register+0x67/0xb0
[ 3.246412] ? e1000_init_module+0x34/0x34
[ 3.246412] do_one_initcall+0x41/0x1b4
[ 3.246412] kernel_init_freeable+0x15a/0x1e7
[ 3.246412] ? rest_init+0x9a/0x9a
[ 3.246412] kernel_init+0x5/0xf6
[ 3.246412] ret_from_fork+0x35/0x40
[ 3.246412] Modules linked in:
[ 3.246412] CR2: 00000000482444ab
[ 3.246412] ---[ end trace 19f70173fca0a2aa ]---
[ 3.246412] RIP: 0010:__hw_addr_add_ex+0xa/0xf0
[ 3.246412] Code: 10 01 49 89 5f 08 48 83 c4 08 5b 5d 41 5c 41 5d
41 5e 41 5f c3 b8 f4 ff ff ff eb ea 0f 1f 40 00 41 57 41 56 41 55 41
54 55 53 <48> 83 8c 10 8b 44 24 48 89 4c 24 08 44 89 04 24 44 89 4c 24
04 89
[ 3.246412] RSP: 0000:ffff9d614002fc48 EFLAGS: 00010246
[ 3.246412] RAX: 0000000000000000 RBX: ffff975d9c17c000 RCX: 0000000000000001
[ 3.246412] RDX: 0000000000000020 RSI: ffff9d614002fc88 RDI: ffff975d9c17c290
[ 3.246412] RBP: ffff975d9c17c000 R08: 0000000000000000 R09: 0000000000000000
[ 3.246412] R10: ffff975d9da8ee68 R11: 00000000ffffffff R12: 0000000000000008
[ 3.246412] R13: ffffffffab8ba5bc R14: 0000000000000000 R15: ffffffffaafc93d0
[ 3.246412] FS: 0000000000000000(0000) GS:ffff975d9fa80000(0000)
knlGS:0000000000000000
[ 3.246412] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.246412] CR2: 00000000482444ab CR3: 0000000211c0a001 CR4: 00000000003606e0
[ 3.246412] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 3.246412] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 3.670747] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000009
[ 3.670747]
[ 3.679456] Kernel Offset: 0x29600000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 3.679456] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x00000009
[ 3.679456] ]---
[ 3.701024] ------------[ cut here ]------------
[ 3.702023] sched: Unexpected reschedule of offline CPU#2!
[ 3.702023] WARNING: CPU: 1 PID: 1 at arch/x86/kernel/smp.c:128
native_smp_send_reschedule+0x2f/0x40

ref:
[1] https://lkft.validation.linaro.org/scheduler/job/1379024#L744
[2] https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.116-41-gdf86600ce713/testrun/1379024/

--
Linaro LKFT
https://lkft.linaro.org

2020-04-21 09:56:24

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/40] 4.19.117-rc1 review


On 20/04/2020 13:39, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.117 release.
> There are 40 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 Wed, 22 Apr 2020 12:10:36 +0000.
> 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.19.117-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.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------


All tests are passing for Tegra ...

Test results for stable-v4.19:
11 builds: 11 pass, 0 fail
22 boots: 22 pass, 0 fail
32 tests: 32 pass, 0 fail

Linux version: 4.19.117-rc1-gdf86600ce713
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

--
nvpublic

2020-04-21 09:58:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/40] 4.19.117-rc1 review

On Tue, Apr 21, 2020 at 03:54:20AM +0530, Naresh Kamboju wrote:
> On Mon, 20 Apr 2020 at 18:21, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 4.19.117 release.
> > There are 40 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 Wed, 22 Apr 2020 12:10:36 +0000.
> > 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.19.117-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.19.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
>
> Results from Linaro’s test farm.
> Regressions on x86_64.
>
> x86_64 boot failed due to kernel BUG and kernel panic.
> It is hard to reproduce this BUG and kernel panic
> We are investigating this problem. The full log links are at [1] and [2].

THanks for testing all of these and if you find an offending commit for
this, please let me know.

thanks,

greg k-h

2020-04-21 09:58:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/40] 4.19.117-rc1 review

On Mon, Apr 20, 2020 at 02:17:02PM +0000, Chris Paterson wrote:
> Hello Greg,
>
> > From: [email protected] <[email protected]> On
> > Behalf Of Greg Kroah-Hartman
> > Sent: 20 April 2020 13:39
> >
> > This is the start of the stable review cycle for the 4.19.117 release.
> > There are 40 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.
>
> No build/boot issues seen for CIP configs for Linux 4.19.117-rc1 (df86600ce713).
>
> Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/137867597
> GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.19.y.yml
> Relevant LAVA jobs: https://lava.ciplatform.org/scheduler/alljobs?length=25&search=df86600ce#table

Great, thanks for letting me know.

greg k-h

2020-04-21 20:08:42

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/40] 4.19.117-rc1 review

On 4/20/20 6:39 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.117 release.
> There are 40 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 Wed, 22 Apr 2020 12:10:36 +0000.
> 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.19.117-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.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

2020-04-22 17:56:12

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/40] 4.19.117-rc1 review

On Tue, 2020-04-21 at 03:54 +0530, Naresh Kamboju wrote:
> On Mon, 20 Apr 2020 at 18:21, Greg Kroah-Hartman
> <[email protected]> wrote:
> > This is the start of the stable review cycle for the 4.19.117 release.
> > There are 40 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 Wed, 22 Apr 2020 12:10:36 +0000.
> > 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.19.117-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.19.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Results from Linaro’s test farm.
> Regressions on x86_64.
>
> x86_64 boot failed due to kernel BUG and kernel panic.
> It is hard to reproduce this BUG and kernel panic
> We are investigating this problem. The full log links are at [1] and [2].
>
> [ 0.000000] Linux version 4.19.117-rc1+ (TuxBuild@f0f6d9b6cd32) (gcc
> version 9.3.0 (Debian 9.3.0-8)) #1 SMP Mon Apr 20 12:40:09 UTC 2020
> <>
> [ 3.237717] igb 0000:01:00.0: Using MSI-X interrupts. 4 rx
> queue(s), 4 tx queue(s)
> [ 3.246412] BUG: unable to handle kernel paging request at 00000000482444ab
> [ 3.246412] PGD 0 P4D 0
> [ 3.246412] Oops: 0002 [#1] SMP PTI
> [ 3.246412] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.19.117-rc1+ #1
> [ 3.246412] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> 2.0b 07/27/2017
> [ 3.246412] RIP: 0010:__hw_addr_add_ex+0xa/0xf0
> [ 3.246412] Code: 10 01 49 89 5f 08 48 83 c4 08 5b 5d 41 5c 41 5d
> 41 5e 41 5f c3 b8 f4 ff ff ff eb ea 0f 1f 40 00 41 57 41 56 41 55 41
> 54 55 53 <48> 83 8c 10 8b 44 24 48 89 4c 24 08 44 89 04 24 44 89 4c 24
> 04 89

The code from start of function to the faulting instruction is:

__hw_addr_add_ex: 41 57 push %r15
__hw_addr_add_ex+2: 41 56 push %r14
__hw_addr_add_ex+4: 41 55 push %r13
__hw_addr_add_ex+6: 41 54 push %r12
__hw_addr_add_ex+8: 55 push %rbp
__hw_addr_add_ex+9: 53 push %rbx
__hw_addr_add_ex+a: 48 83 8c 10 8b 44 24 orq $0xffffffffffffff89,0x4824448b(%rax,%rdx,1)

But in a Debian compiled 4.19 kernel the function starts with:

ffffffff815ec470: e8 8b 53 21 00 callq 0xffffffff81801800
ffffffff815ec475: 41 57 push %r15
ffffffff815ec477: 41 56 push %r14
ffffffff815ec479: 41 55 push %r13
ffffffff815ec47b: 41 54 push %r12
ffffffff815ec47d: 55 push %rbp
ffffffff815ec47e: 53 push %rbx
ffffffff815ec47f: 48 83 ec 10 sub $0x10,%rsp
ffffffff815ec483: 8b 44 24 48 mov 0x48(%rsp),%eax

(the first instruction is added by ftrace).

It looks like one byte of the faulting instruction has been corrupted
somehow. So this function itself is probably not to blame. It may be
worth running a memory test on the test system.

Ben.

> [ 3.246412] RSP: 0000:ffff9d614002fc48 EFLAGS: 00010246
> [ 3.246412] RAX: 0000000000000000 RBX: ffff975d9c17c000 RCX: 0000000000000001
> [ 3.246412] RDX: 0000000000000020 RSI: ffff9d614002fc88 RDI: ffff975d9c17c290
> [ 3.246412] RBP: ffff975d9c17c000 R08: 0000000000000000 R09: 0000000000000000
> [ 3.246412] R10: ffff975d9da8ee68 R11: 00000000ffffffff R12: 0000000000000008
> [ 3.246412] R13: ffffffffab8ba5bc R14: 0000000000000000 R15: ffffffffaafc93d0
> [ 3.246412] FS: 0000000000000000(0000) GS:ffff975d9fa80000(0000)
> knlGS:0000000000000000
> [ 3.246412] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 3.438798] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [ 3.246412] CR2: 00000000482444ab CR3: 0000000211c0a001 CR4: 00000000003606e0
> [ 3.246412] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 3.246412] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 3.246412] Call Trace:
> [ 3.246412] ? eth_header+0xb0/0xb0
> [ 3.246412] dev_addr_init+0x76/0xb0
> [ 3.448543] ata4: SATA link down (SStatus 0 SControl 300)
> [ 3.246412] alloc_netdev_mqs+0x9d/0x3e0
> [ 3.246412] igb_probe+0x16e/0x14d0
> [ 3.462804] ata7: SATA link down (SStatus 0 SControl 300)
> [ 3.246412] local_pci_probe+0x3e/0x90
> [ 3.246412] pci_device_probe+0x102/0x1a0
> [ 3.246412] really_probe+0x1be/0x260
> [ 3.472410] ata5: SATA link down (SStatus 0 SControl 300)
> [ 3.246412] driver_probe_device+0x4b/0x90
> [ 3.246412] __driver_attach+0xbb/0xc0
> [ 3.246412] ? driver_probe_device+0x90/0x90
> [ 3.246412] bus_for_each_dev+0x73/0xb0
> [ 3.246412] bus_add_driver+0x192/0x1d0
> [ 3.246412] driver_register+0x67/0xb0
> [ 3.246412] ? e1000_init_module+0x34/0x34
> [ 3.246412] do_one_initcall+0x41/0x1b4
> [ 3.246412] kernel_init_freeable+0x15a/0x1e7
> [ 3.246412] ? rest_init+0x9a/0x9a
> [ 3.246412] kernel_init+0x5/0xf6
> [ 3.246412] ret_from_fork+0x35/0x40
> [ 3.246412] Modules linked in:
> [ 3.246412] CR2: 00000000482444ab
> [ 3.246412] ---[ end trace 19f70173fca0a2aa ]---
> [ 3.246412] RIP: 0010:__hw_addr_add_ex+0xa/0xf0
> [ 3.246412] Code: 10 01 49 89 5f 08 48 83 c4 08 5b 5d 41 5c 41 5d
> 41 5e 41 5f c3 b8 f4 ff ff ff eb ea 0f 1f 40 00 41 57 41 56 41 55 41
> 54 55 53 <48> 83 8c 10 8b 44 24 48 89 4c 24 08 44 89 04 24 44 89 4c 24
> 04 89
> [ 3.246412] RSP: 0000:ffff9d614002fc48 EFLAGS: 00010246
> [ 3.246412] RAX: 0000000000000000 RBX: ffff975d9c17c000 RCX: 0000000000000001
> [ 3.246412] RDX: 0000000000000020 RSI: ffff9d614002fc88 RDI: ffff975d9c17c290
> [ 3.246412] RBP: ffff975d9c17c000 R08: 0000000000000000 R09: 0000000000000000
> [ 3.246412] R10: ffff975d9da8ee68 R11: 00000000ffffffff R12: 0000000000000008
> [ 3.246412] R13: ffffffffab8ba5bc R14: 0000000000000000 R15: ffffffffaafc93d0
> [ 3.246412] FS: 0000000000000000(0000) GS:ffff975d9fa80000(0000)
> knlGS:0000000000000000
> [ 3.246412] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 3.246412] CR2: 00000000482444ab CR3: 0000000211c0a001 CR4: 00000000003606e0
> [ 3.246412] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 3.246412] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 3.670747] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x00000009
> [ 3.670747]
> [ 3.679456] Kernel Offset: 0x29600000 from 0xffffffff81000000
> (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> [ 3.679456] ---[ end Kernel panic - not syncing: Attempted to kill
> init! exitcode=0x00000009
> [ 3.679456] ]---
> [ 3.701024] ------------[ cut here ]------------
> [ 3.702023] sched: Unexpected reschedule of offline CPU#2!
> [ 3.702023] WARNING: CPU: 1 PID: 1 at arch/x86/kernel/smp.c:128
> native_smp_send_reschedule+0x2f/0x40
>
> ref:
> [1] https://lkft.validation.linaro.org/scheduler/job/1379024#L744
> [2] https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.116-41-gdf86600ce713/testrun/1379024/
>
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom