[PATCH 4.14 00/14] 4.14.230-rc1 review

[PATCH 4.14 00/14] 4.14.230-rc1 review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 4.14.230 release.
There are 14 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 Sun, 11 Apr 2021 09:52:52 +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.14.230-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 4.14.230-rc1

Masahiro Yamada <masahiroy@kernel.org>
    init/Kconfig: make COMPILE_TEST depend on HAS_IOMEM

Heiko Carstens <hca@linux.ibm.com>
    init/Kconfig: make COMPILE_TEST depend on !S390

Piotr Krysiuk <piotras@gmail.com>
    bpf, x86: Validate computation of branch displacements for x86-64

Vincent Whitchurch <vincent.whitchurch@axis.com>
    cifs: Silently ignore unknown oplock break handle

Ronnie Sahlberg <lsahlber@redhat.com>
    cifs: revalidate mapping when we open files for SMB1 POSIX

Sergei Trofimovich <slyfox@gentoo.org>
    ia64: mca: allocate early mca with GFP_ATOMIC

Martin Wilck <mwilck@suse.com>
    scsi: target: pscsi: Clean up after failure in pscsi_map_sg()

Arnd Bergmann <arnd@arndb.de>
    x86/build: Turn off -fcf-protection for realmode targets

Esteve Varela Colominas <esteve.varela@gmail.com>
    platform/x86: thinkpad_acpi: Allow the FnLock LED to change state

Rob Clark <robdclark@chromium.org>
    drm/msm: Ratelimit invalid-fence message

Karthikeyan Kathirvel <kathirve@codeaurora.org>
    mac80211: choose first enabled channel for monitor

Tong Zhang <ztong0001@gmail.com>
    mISDN: fix crash in fritzpci

Pavel Andrianov <andrianov@ispras.ru>
    net: pxa168_eth: Fix a potential data race in pxa168_eth_remove

Mans Rullgard <mans@mansr.com>
    ARM: dts: am33xx: add aliases for mmc interfaces


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

Diffstat:

 Makefile                                  |  4 ++--
 arch/arm/boot/dts/am33xx.dtsi             |  3 +++
 arch/ia64/kernel/mca.c                    |  2 +-
 arch/x86/Makefile                         |  2 +-
 arch/x86/net/bpf_jit_comp.c               | 11 ++++++++++-
 drivers/gpu/drm/msm/msm_fence.c           |  2 +-
 drivers/isdn/hardware/mISDN/mISDNipac.c   |  2 +-
 drivers/net/ethernet/marvell/pxa168_eth.c |  2 +-
 drivers/platform/x86/thinkpad_acpi.c      |  8 +++++++-
 drivers/target/target_core_pscsi.c        |  8 ++++++++
 fs/cifs/file.c                            |  1 +
 fs/cifs/smb2misc.c                        |  4 ++--
 init/Kconfig                              |  3 +--
 net/mac80211/main.c                       | 13 ++++++++++++-
 14 files changed, 51 insertions(+), 14 deletions(-)

[PATCH 4.14 01/14] ARM: dts: am33xx: add aliases for mmc interfaces

[Greg Kroah-Hartman]

From: Mans Rullgard <mans@mansr.com>

[ Upstream commit 9bbce32a20d6a72c767a7f85fd6127babd1410ac ]

Without DT aliases, the numbering of mmc interfaces is unpredictable.
Adding them makes it possible to refer to devices consistently.  The
popular suggestion to use UUIDs obviously doesn't work with a blank
device fresh from the factory.

See commit fa2d0aa96941 ("mmc: core: Allow setting slot index via
device tree alias") for more discussion.

Signed-off-by: Mans Rullgard <mans@mansr.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/arm/boot/dts/am33xx.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index e58fab8aec5d..8923273a2f73 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -38,6 +38,9 @@ aliases {
 		ethernet1 = &cpsw_emac1;
 		spi0 = &spi0;
 		spi1 = &spi1;
+		mmc0 = &mmc1;
+		mmc1 = &mmc2;
+		mmc2 = &mmc3;
 	};
 
 	cpus {
-- 
2.30.2

[PATCH 4.14 02/14] net: pxa168_eth: Fix a potential data race in pxa168_eth_remove

[Greg Kroah-Hartman]

From: Pavel Andrianov <andrianov@ispras.ru>

[ Upstream commit 0571a753cb07982cc82f4a5115e0b321da89e1f3 ]

pxa168_eth_remove() firstly calls unregister_netdev(),
then cancels a timeout work. unregister_netdev() shuts down a device
interface and removes it from the kernel tables. If the timeout occurs
in parallel, the timeout work (pxa168_eth_tx_timeout_task) performs stop
and open of the device. It may lead to an inconsistent state and memory
leaks.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Pavel Andrianov <andrianov@ispras.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/net/ethernet/marvell/pxa168_eth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c b/drivers/net/ethernet/marvell/pxa168_eth.c
index 993724959a7c..1883f0d076e3 100644
--- a/drivers/net/ethernet/marvell/pxa168_eth.c
+++ b/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -1553,8 +1553,8 @@ static int pxa168_eth_remove(struct platform_device *pdev)
 
 	mdiobus_unregister(pep->smi_bus);
 	mdiobus_free(pep->smi_bus);
-	unregister_netdev(dev);
 	cancel_work_sync(&pep->tx_timeout_task);
+	unregister_netdev(dev);
 	free_netdev(dev);
 	return 0;
 }
-- 
2.30.2

[PATCH 4.14 03/14] mISDN: fix crash in fritzpci

[Greg Kroah-Hartman]

From: Tong Zhang <ztong0001@gmail.com>

[ Upstream commit a9f81244d2e33e6dfcef120fefd30c96b3f7cdb0 ]

setup_fritz() in avmfritz.c might fail with -EIO and in this case the
isac.type and isac.write_reg is not initialized and remains 0(NULL).
A subsequent call to isac_release() will dereference isac->write_reg and
crash.

[    1.737444] BUG: kernel NULL pointer dereference, address: 0000000000000000
[    1.737809] #PF: supervisor instruction fetch in kernel mode
[    1.738106] #PF: error_code(0x0010) - not-present page
[    1.738378] PGD 0 P4D 0
[    1.738515] Oops: 0010 [#1] SMP NOPTI
[    1.738711] CPU: 0 PID: 180 Comm: systemd-udevd Not tainted 5.12.0-rc2+ #78
[    1.739077] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda519-p
rebuilt.qemu.org 04/01/2014
[    1.739664] RIP: 0010:0x0
[    1.739807] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
[    1.740200] RSP: 0018:ffffc9000027ba10 EFLAGS: 00010202
[    1.740478] RAX: 0000000000000000 RBX: ffff888102f41840 RCX: 0000000000000027
[    1.740853] RDX: 00000000000000ff RSI: 0000000000000020 RDI: ffff888102f41800
[    1.741226] RBP: ffffc9000027ba20 R08: ffff88817bc18440 R09: ffffc9000027b808
[    1.741600] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888102f41840
[    1.741976] R13: 00000000fffffffb R14: ffff888102f41800 R15: ffff8881008b0000
[    1.742351] FS:  00007fda3a38a8c0(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
[    1.742774] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.743076] CR2: ffffffffffffffd6 CR3: 00000001021ec000 CR4: 00000000000006f0
[    1.743452] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    1.743828] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    1.744206] Call Trace:
[    1.744339]  isac_release+0xcc/0xe0 [mISDNipac]
[    1.744582]  fritzpci_probe.cold+0x282/0x739 [avmfritz]
[    1.744861]  local_pci_probe+0x48/0x80
[    1.745063]  pci_device_probe+0x10f/0x1c0
[    1.745278]  really_probe+0xfb/0x420
[    1.745471]  driver_probe_device+0xe9/0x160
[    1.745693]  device_driver_attach+0x5d/0x70
[    1.745917]  __driver_attach+0x8f/0x150
[    1.746123]  ? device_driver_attach+0x70/0x70
[    1.746354]  bus_for_each_dev+0x7e/0xc0
[    1.746560]  driver_attach+0x1e/0x20
[    1.746751]  bus_add_driver+0x152/0x1f0
[    1.746957]  driver_register+0x74/0xd0
[    1.747157]  ? 0xffffffffc00d8000
[    1.747334]  __pci_register_driver+0x54/0x60
[    1.747562]  AVM_init+0x36/0x1000 [avmfritz]
[    1.747791]  do_one_initcall+0x48/0x1d0
[    1.747997]  ? __cond_resched+0x19/0x30
[    1.748206]  ? kmem_cache_alloc_trace+0x390/0x440
[    1.748458]  ? do_init_module+0x28/0x250
[    1.748669]  do_init_module+0x62/0x250
[    1.748870]  load_module+0x23ee/0x26a0
[    1.749073]  __do_sys_finit_module+0xc2/0x120
[    1.749307]  ? __do_sys_finit_module+0xc2/0x120
[    1.749549]  __x64_sys_finit_module+0x1a/0x20
[    1.749782]  do_syscall_64+0x38/0x90

Signed-off-by: Tong Zhang <ztong0001@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/isdn/hardware/mISDN/mISDNipac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/isdn/hardware/mISDN/mISDNipac.c b/drivers/isdn/hardware/mISDN/mISDNipac.c
index e240010b93fa..c87cb193830c 100644
--- a/drivers/isdn/hardware/mISDN/mISDNipac.c
+++ b/drivers/isdn/hardware/mISDN/mISDNipac.c
@@ -711,7 +711,7 @@ isac_release(struct isac_hw *isac)
 {
 	if (isac->type & IPAC_TYPE_ISACX)
 		WriteISAC(isac, ISACX_MASK, 0xff);
-	else
+	else if (isac->type != 0)
 		WriteISAC(isac, ISAC_MASK, 0xff);
 	if (isac->dch.timer.function != NULL) {
 		del_timer(&isac->dch.timer);
-- 
2.30.2

[PATCH 4.14 04/14] mac80211: choose first enabled channel for monitor

[Greg Kroah-Hartman]

From: Karthikeyan Kathirvel <kathirve@codeaurora.org>

[ Upstream commit 041c881a0ba8a75f71118bd9766b78f04beed469 ]

Even if the first channel from sband channel list is invalid
or disabled mac80211 ends up choosing it as the default channel
for monitor interfaces, making them not usable.

Fix this by assigning the first available valid or enabled
channel instead.

Signed-off-by: Karthikeyan Kathirvel <kathirve@codeaurora.org>
Link: https://lore.kernel.org/r/1615440547-7661-1-git-send-email-kathirve@codeaurora.org
[reword commit message, comment, code cleanups]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 net/mac80211/main.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 8a51f94ec1ce..2136ce3b4489 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -913,8 +913,19 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
 			continue;
 
 		if (!dflt_chandef.chan) {
+			/*
+			 * Assign the first enabled channel to dflt_chandef
+			 * from the list of channels
+			 */
+			for (i = 0; i < sband->n_channels; i++)
+				if (!(sband->channels[i].flags &
+						IEEE80211_CHAN_DISABLED))
+					break;
+			/* if none found then use the first anyway */
+			if (i == sband->n_channels)
+				i = 0;
 			cfg80211_chandef_create(&dflt_chandef,
-						&sband->channels[0],
+						&sband->channels[i],
 						NL80211_CHAN_NO_HT);
 			/* init channel we're on */
 			if (!local->use_chanctx && !local->_oper_chandef.chan) {
-- 
2.30.2

[PATCH 4.14 05/14] drm/msm: Ratelimit invalid-fence message

[Greg Kroah-Hartman]

From: Rob Clark <robdclark@chromium.org>

[ Upstream commit 7ad48d27a2846bfda29214fb454d001c3e02b9e7 ]

We have seen a couple cases where low memory situations cause something
bad to happen, followed by a flood of these messages obscuring the root
cause.  Lets ratelimit the dmesg spam so that next time it happens we
don't lose the kernel traces leading up to this.

Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/gpu/drm/msm/msm_fence.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c
index a2f89bac9c16..4c0ac0360b93 100644
--- a/drivers/gpu/drm/msm/msm_fence.c
+++ b/drivers/gpu/drm/msm/msm_fence.c
@@ -56,7 +56,7 @@ int msm_wait_fence(struct msm_fence_context *fctx, uint32_t fence,
 	int ret;
 
 	if (fence > fctx->last_fence) {
-		DRM_ERROR("%s: waiting on invalid fence: %u (of %u)\n",
+		DRM_ERROR_RATELIMITED("%s: waiting on invalid fence: %u (of %u)\n",
 				fctx->name, fence, fctx->last_fence);
 		return -EINVAL;
 	}
-- 
2.30.2

[PATCH 4.14 06/14] platform/x86: thinkpad_acpi: Allow the FnLock LED to change state

[Greg Kroah-Hartman]

From: Esteve Varela Colominas <esteve.varela@gmail.com>

[ Upstream commit 3d677f12ea3a2097a16ded570623567403dea959 ]

On many recent ThinkPad laptops, there's a new LED next to the ESC key,
that indicates the FnLock status.
When the Fn+ESC combo is pressed, FnLock is toggled, which causes the
Media Key functionality to change, making it so that the media keys
either perform their media key function, or function as an F-key by
default. The Fn key can be used the access the alternate function at any
time.

With the current linux kernel, the LED doens't change state if you press
the Fn+ESC key combo. However, the media key functionality *does*
change. This is annoying, since the LED will stay on if it was on during
bootup, and it makes it hard to keep track what the current state of the
FnLock is.

This patch calls an ACPI function, that gets the current media key
state, when the Fn+ESC key combo is pressed. Through testing it was
discovered that this function causes the LED to update correctly to
reflect the current state when this function is called.

The relevant ACPI calls are the following:
\_SB_.PCI0.LPC0.EC0_.HKEY.GMKS: Get media key state, returns 0x603 if the FnLock mode is enabled, and 0x602 if it's disabled.
\_SB_.PCI0.LPC0.EC0_.HKEY.SMKS: Set media key state, sending a 1 will enable FnLock mode, and a 0 will disable it.

Relevant discussion:
https://bugzilla.kernel.org/show_bug.cgi?id=207841
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1881015

Signed-off-by: Esteve Varela Colominas <esteve.varela@gmail.com>
Link: https://lore.kernel.org/r/20210315195823.23212-1-esteve.varela@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/platform/x86/thinkpad_acpi.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index ffaaccded34e..30bfd51c0e58 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -3964,13 +3964,19 @@ static bool hotkey_notify_6xxx(const u32 hkey,
 
 	case TP_HKEY_EV_KEY_NUMLOCK:
 	case TP_HKEY_EV_KEY_FN:
-	case TP_HKEY_EV_KEY_FN_ESC:
 		/* key press events, we just ignore them as long as the EC
 		 * is still reporting them in the normal keyboard stream */
 		*send_acpi_ev = false;
 		*ignore_acpi_ev = true;
 		return true;
 
+	case TP_HKEY_EV_KEY_FN_ESC:
+		/* Get the media key status to foce the status LED to update */
+		acpi_evalf(hkey_handle, NULL, "GMKS", "v");
+		*send_acpi_ev = false;
+		*ignore_acpi_ev = true;
+		return true;
+
 	case TP_HKEY_EV_TABLET_CHANGED:
 		tpacpi_input_send_tabletsw();
 		hotkey_tablet_mode_notify_change();
-- 
2.30.2

[PATCH 4.14 07/14] x86/build: Turn off -fcf-protection for realmode targets

[Greg Kroah-Hartman]

From: Arnd Bergmann <arnd@arndb.de>

[ Upstream commit 9fcb51c14da2953de585c5c6e50697b8a6e91a7b ]

The new Ubuntu GCC packages turn on -fcf-protection globally,
which causes a build failure in the x86 realmode code:

  cc1: error: ‘-fcf-protection’ is not compatible with this target

Turn it off explicitly on compilers that understand this option.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210323124846.1584944-1-arnd@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/x86/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 9f33a69b5605..146aadeb7c8e 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -35,7 +35,7 @@ REALMODE_CFLAGS	:= $(M16_CFLAGS) -g -Os -D__KERNEL__ \
 		   -DDISABLE_BRANCH_PROFILING \
 		   -Wall -Wstrict-prototypes -march=i386 -mregparm=3 \
 		   -fno-strict-aliasing -fomit-frame-pointer -fno-pic \
-		   -mno-mmx -mno-sse
+		   -mno-mmx -mno-sse $(call cc-option,-fcf-protection=none)
 
 REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -ffreestanding)
 REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -fno-stack-protector)
-- 
2.30.2

[PATCH 4.14 08/14] scsi: target: pscsi: Clean up after failure in pscsi_map_sg()

[Greg Kroah-Hartman]

From: Martin Wilck <mwilck@suse.com>

[ Upstream commit 36fa766faa0c822c860e636fe82b1affcd022974 ]

If pscsi_map_sg() fails, make sure to drop references to already allocated
bios.

Link: https://lore.kernel.org/r/20210323212431.15306-2-mwilck@suse.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/target/target_core_pscsi.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/target/target_core_pscsi.c b/drivers/target/target_core_pscsi.c
index 6cb933ecc084..f80b31b35a0d 100644
--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
@@ -949,6 +949,14 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist *sgl, u32 sgl_nents,
 
 	return 0;
 fail:
+	if (bio)
+		bio_put(bio);
+	while (req->bio) {
+		bio = req->bio;
+		req->bio = bio->bi_next;
+		bio_put(bio);
+	}
+	req->biotail = NULL;
 	return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
 }
 
-- 
2.30.2

[PATCH 4.14 09/14] ia64: mca: allocate early mca with GFP_ATOMIC

[Greg Kroah-Hartman]

From: Sergei Trofimovich <slyfox@gentoo.org>

[ Upstream commit f2a419cf495f95cac49ea289318b833477e1a0e2 ]

The sleep warning happens at early boot right at secondary CPU
activation bootup:

    smp: Bringing up secondary CPUs ...
    BUG: sleeping function called from invalid context at mm/page_alloc.c:4942
    in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
    CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.12.0-rc2-00007-g79e228d0b611-dirty #99
    ..
    Call Trace:
      show_stack+0x90/0xc0
      dump_stack+0x150/0x1c0
      ___might_sleep+0x1c0/0x2a0
      __might_sleep+0xa0/0x160
      __alloc_pages_nodemask+0x1a0/0x600
      alloc_page_interleave+0x30/0x1c0
      alloc_pages_current+0x2c0/0x340
      __get_free_pages+0x30/0xa0
      ia64_mca_cpu_init+0x2d0/0x3a0
      cpu_init+0x8b0/0x1440
      start_secondary+0x60/0x700
      start_ap+0x750/0x780
    Fixed BSP b0 value from CPU 1

As I understand interrupts are not enabled yet and system has a lot of
memory.  There is little chance to sleep and switch to GFP_ATOMIC should
be a no-op.

Link: https://lkml.kernel.org/r/20210315085045.204414-1-slyfox@gentoo.org
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.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>
---
 arch/ia64/kernel/mca.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
index 555b11180156..16a7dae5f770 100644
--- a/arch/ia64/kernel/mca.c
+++ b/arch/ia64/kernel/mca.c
@@ -1860,7 +1860,7 @@ ia64_mca_cpu_init(void *cpu_data)
 			data = mca_bootmem();
 			first_time = 0;
 		} else
-			data = (void *)__get_free_pages(GFP_KERNEL,
+			data = (void *)__get_free_pages(GFP_ATOMIC,
 							get_order(sz));
 		if (!data)
 			panic("Could not allocate MCA memory for cpu %d\n",
-- 
2.30.2

[PATCH 4.14 10/14] cifs: revalidate mapping when we open files for SMB1 POSIX

[Greg Kroah-Hartman]

From: Ronnie Sahlberg <lsahlber@redhat.com>

[ Upstream commit cee8f4f6fcabfdf229542926128e9874d19016d5 ]

RHBZ: 1933527

Under SMB1 + POSIX, if an inode is reused on a server after we have read and
cached a part of a file, when we then open the new file with the
re-cycled inode there is a chance that we may serve the old data out of cache
to the application.
This only happens for SMB1 (deprecated) and when posix are used.
The simplest solution to avoid this race is to force a revalidate
on smb1-posix open.

Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/cifs/file.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 6c77a96437e6..46e8e9324b58 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -163,6 +163,7 @@ int cifs_posix_open(char *full_path, struct inode **pinode,
 			goto posix_open_ret;
 		}
 	} else {
+		cifs_revalidate_mapping(*pinode);
 		cifs_fattr_to_inode(*pinode, &fattr);
 	}
 
-- 
2.30.2

[PATCH 4.14 11/14] cifs: Silently ignore unknown oplock break handle

[Greg Kroah-Hartman]

From: Vincent Whitchurch <vincent.whitchurch@axis.com>

[ Upstream commit 219481a8f90ec3a5eed9638fb35609e4b1aeece7 ]

Make SMB2 not print out an error when an oplock break is received for an
unknown handle, similar to SMB1.  The debug message which is printed for
these unknown handles may also be misleading, so fix that too.

The SMB2 lease break path is not affected by this patch.

Without this, a program which writes to a file from one thread, and
opens, reads, and writes the same file from another thread triggers the
below errors several times a minute when run against a Samba server
configured with "smb2 leases = no".

 CIFS: VFS: \\192.168.0.1 No task to wake, unknown frame received! NumMids 2
 00000000: 424d53fe 00000040 00000000 00000012  .SMB@...........
 00000010: 00000001 00000000 ffffffff ffffffff  ................
 00000020: 00000000 00000000 00000000 00000000  ................
 00000030: 00000000 00000000 00000000 00000000  ................

Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Reviewed-by: Tom Talpey <tom@talpey.com>
Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/cifs/smb2misc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/cifs/smb2misc.c b/fs/cifs/smb2misc.c
index 0c6e5450ff76..80339e318294 100644
--- a/fs/cifs/smb2misc.c
+++ b/fs/cifs/smb2misc.c
@@ -656,8 +656,8 @@ smb2_is_valid_oplock_break(char *buffer, struct TCP_Server_Info *server)
 		}
 	}
 	spin_unlock(&cifs_tcp_ses_lock);
-	cifs_dbg(FYI, "Can not process oplock break for non-existent connection\n");
-	return false;
+	cifs_dbg(FYI, "No file id matched, oplock break ignored\n");
+	return true;
 }
 
 void
-- 
2.30.2

[PATCH 4.14 12/14] bpf, x86: Validate computation of branch displacements for x86-64

[Greg Kroah-Hartman]

From: Piotr Krysiuk <piotras@gmail.com>

commit e4d4d456436bfb2fe412ee2cd489f7658449b098 upstream.

The branch displacement logic in the BPF JIT compilers for x86 assumes
that, for any generated branch instruction, the distance cannot
increase between optimization passes.

But this assumption can be violated due to how the distances are
computed. Specifically, whenever a backward branch is processed in
do_jit(), the distance is computed by subtracting the positions in the
machine code from different optimization passes. This is because part
of addrs[] is already updated for the current optimization pass, before
the branch instruction is visited.

And so the optimizer can expand blocks of machine code in some cases.

This can confuse the optimizer logic, where it assumes that a fixed
point has been reached for all machine code blocks once the total
program size stops changing. And then the JIT compiler can output
abnormal machine code containing incorrect branch displacements.

To mitigate this issue, we assert that a fixed point is reached while
populating the output image. This rejects any problematic programs.
The issue affects both x86-32 and x86-64. We mitigate separately to
ease backporting.

Signed-off-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/x86/net/bpf_jit_comp.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -1107,7 +1107,16 @@ common_load:
 		}
 
 		if (image) {
-			if (unlikely(proglen + ilen > oldproglen)) {
+			/*
+			 * When populating the image, assert that:
+			 *
+			 *  i) We do not write beyond the allocated space, and
+			 * ii) addrs[i] did not change from the prior run, in order
+			 *     to validate assumptions made for computing branch
+			 *     displacements.
+			 */
+			if (unlikely(proglen + ilen > oldproglen ||
+				     proglen + ilen != addrs[i])) {
 				pr_err("bpf_jit: fatal error\n");
 				return -EFAULT;
 			}

[PATCH 4.14 13/14] init/Kconfig: make COMPILE_TEST depend on !S390

[Greg Kroah-Hartman]

From: Heiko Carstens <hca@linux.ibm.com>

commit 334ef6ed06fa1a54e35296b77b693bcf6d63ee9e upstream.

While allmodconfig and allyesconfig build for s390 there are also
various bots running compile tests with randconfig, where PCI is
disabled. This reveals that a lot of drivers should actually depend on
HAS_IOMEM.
Adding this to each device driver would be a never ending story,
therefore just disable COMPILE_TEST for s390.

The reasoning is more or less the same as described in
commit bc083a64b6c0 ("init/Kconfig: make COMPILE_TEST depend on !UML").

Reported-by: kernel test robot <lkp@intel.com>
Suggested-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 init/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/init/Kconfig
+++ b/init/Kconfig
@@ -65,7 +65,7 @@ config CROSS_COMPILE
 
 config COMPILE_TEST
 	bool "Compile also drivers which will not load"
-	depends on !UML
+	depends on !UML && !S390
 	default n
 	help
 	  Some drivers can be compiled on a different platform than they are

[PATCH 4.14 14/14] init/Kconfig: make COMPILE_TEST depend on HAS_IOMEM

[Greg Kroah-Hartman]

From: Masahiro Yamada <masahiroy@kernel.org>

commit ea29b20a828511de3348334e529a3d046a180416 upstream.

I read the commit log of the following two:

- bc083a64b6c0 ("init/Kconfig: make COMPILE_TEST depend on !UML")
- 334ef6ed06fa ("init/Kconfig: make COMPILE_TEST depend on !S390")

Both are talking about HAS_IOMEM dependency missing in many drivers.

So, 'depends on HAS_IOMEM' seems the direct, sensible solution to me.

This does not change the behavior of UML. UML still cannot enable
COMPILE_TEST because it does not provide HAS_IOMEM.

The current dependency for S390 is too strong. Under the condition of
CONFIG_PCI=y, S390 provides HAS_IOMEM, hence can enable COMPILE_TEST.

I also removed the meaningless 'default n'.

Link: https://lkml.kernel.org/r/20210224140809.1067582-1-masahiroy@kernel.org
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: KP Singh <kpsingh@google.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Quentin Perret <qperret@google.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 init/Kconfig |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/init/Kconfig
+++ b/init/Kconfig
@@ -65,8 +65,7 @@ config CROSS_COMPILE
 
 config COMPILE_TEST
 	bool "Compile also drivers which will not load"
-	depends on !UML && !S390
-	default n
+	depends on HAS_IOMEM
 	help
 	  Some drivers can be compiled on a different platform than they are
 	  intended to be run on. Despite they cannot be loaded there (or even

Re: [PATCH 4.14 00/14] 4.14.230-rc1 review

[Guenter Roeck]

On Fri, Apr 09, 2021 at 11:53:25AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.230 release.
> There are 14 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 Sun, 11 Apr 2021 09:52:52 +0000.
> Anything received after that time might be too late.
> 

Build results:
	total: 168 pass: 168 fail: 0
Qemu test results:
	total: 408 pass: 408 fail: 0

Tested-by: Guenter Roeck <linux@roeck-us.net>

Having said this, I did see a spurious crash, and I see an unusual warning.
I have seen the crash only once, but the warning happens with every boot.
These are likely not new but exposed because I added network interface
tests. This is all v4.14.y specific; I did not see it in other branches.
See below for the tracebacks. Maybe someone has seen it before.

Thanks,
Guenter

---
ftgmac100 1e660000.ethernet eth0: NCSI interface down
------------[ cut here ]------------
WARNING: CPU: 0 PID: 477 at drivers/base/dma-mapping.c:325 remap_allocator_free+0x54/0x5c
trying to free invalid coherent area: 909a1000
Modules linked in:
CPU: 0 PID: 477 Comm: ip Not tainted 4.14.230-rc1-00015-gbbc0ac1df344 #1
Hardware name: Generic DT based system
[<8000f8dc>] (unwind_backtrace) from [<8000d194>] (show_stack+0x10/0x14)
[<8000d194>] (show_stack) from [<805a5a80>] (__warn+0xc0/0xf4)
[<805a5a80>] (__warn) from [<800177b4>] (warn_slowpath_fmt+0x38/0x48)
[<800177b4>] (warn_slowpath_fmt) from [<80010554>] (remap_allocator_free+0x54/0x5c)
[<80010554>] (remap_allocator_free) from [<80010e4c>] (__arm_dma_free.constprop.0+0xec/0x13c)
[<80010e4c>] (__arm_dma_free.constprop.0) from [<80429924>] (ftgmac100_free_rings+0x17c/0x1f8)
[<80429924>] (ftgmac100_free_rings) from [<80429a24>] (ftgmac100_stop+0x84/0xa4)
[<80429a24>] (ftgmac100_stop) from [<804e8a70>] (__dev_close_many+0xac/0x100)
[<804e8a70>] (__dev_close_many) from [<804f0dc0>] (__dev_change_flags+0xb4/0x1a0)
[<804f0dc0>] (__dev_change_flags) from [<804f0ec4>] (dev_change_flags+0x18/0x48)
[<804f0ec4>] (dev_change_flags) from [<80561644>] (devinet_ioctl+0x6cc/0x808)
[<80561644>] (devinet_ioctl) from [<804d1548>] (sock_ioctl+0x188/0x2e4)
[<804d1548>] (sock_ioctl) from [<800eac80>] (do_vfs_ioctl+0x3a0/0x82c)
[<800eac80>] (do_vfs_ioctl) from [<800eb140>] (SyS_ioctl+0x34/0x60)
[<800eb140>] (SyS_ioctl) from [<8000a600>] (ret_fast_syscall+0x0/0x28)
---[ end trace c13f2f82f69274ad ]---

=====

ftgmac100 1e660000.ethernet eth0: NCSI interface up
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 9ec84000
[00000000] *pgd=9f7f6831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] ARM
Modules linked in:
CPU: 0 PID: 397 Comm: default.script Not tainted 4.14.230-rc1-00015-gbbc0ac1df344 #1
Hardware name: Generic DT based system
task: 9f5cc260 task.stack: 9ecee000
PC is at anon_vma_clone+0x64/0x19c
LR is at fs_reclaim_release+0x8/0x18
pc : [<800c1ccc>]    lr : [<80098b5c>]    psr: a0000153
sp : 9ecefe78  ip : 00000000  fp : ffffffff
r10: 01000200  r9 : 9f7e6d10  r8 : 80cb9a44
r7 : 9f7e0da0  r6 : 9f7e6d10  r5 : 9ed0f600  r4 : 9f5a562c
r3 : 00000030  r2 : 9fbdf618  r1 : 00000034  r0 : 9ed0f600
Flags: NzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment user
Control: 00c5387d  Table: 9ec84008  DAC: 00000055
Process default.script (pid: 397, stack limit = 0x9ecee188)
Stack: (0x9ecefe78 to 0x9ecf0000)
fe60:                                                       9f5a303c 9f5a3000
fe80: 00000002 9f7e0da0 9f7e0ab4 9f5a3000 9f77e600 9f7e0da0 9f5a3000 9f77e400
fea0: 9f72dc64 800c1e28 9f7e0ab0 9f7e0ab4 00000002 9f77e600 9f7e0da0 800161f8
fec0: 9f5cc640 cacd966c 9f5cc260 cd397f94 80cb0afc 00000000 80016870 00000000
fee0: 00000000 9f69f2f8 9f7e0aa8 807ca224 9f7e0aa0 9f72dc70 9f69f100 00000011
ff00: 9f77e658 9f77e458 9eceff08 9eceff08 9f5cc650 00000011 7eb26888 00000000
ff20: 00000000 00000000 9ecee000 00000000 76eff3a0 80016870 00000000 00000000
ff40: ffffffff 7eb26888 9eceff78 00000000 9ecee000 76ec4a28 7eb26888 9eceff78
ff60: 00000000 7eb26888 00000008 00000000 00000008 800245e4 76efdcd0 7eb26888
ff80: 00000000 00000002 8000a704 9ecee000 00000000 80016cd4 00000000 00000000
ffa0: 9ecee000 8000a520 76efdcd0 7eb26888 76efffcc 00000001 76efe7ac 00000000
ffc0: 76efdcd0 7eb26888 00000000 00000002 7eb26918 76efe000 76f00c60 76eff3a0
ffe0: 000e0350 7eb26888 76e96b94 76e96b98 60000150 76efffcc 00000000 00000000
[<800c1ccc>] (anon_vma_clone) from [<800c1e28>] (anon_vma_fork+0x24/0x138)
[<800c1e28>] (anon_vma_fork) from [<800161f8>] (copy_process.part.0+0x12a4/0x17dc)
[<800161f8>] (copy_process.part.0) from [<80016870>] (_do_fork+0xa0/0x488)
[<80016870>] (_do_fork) from [<80016cd4>] (sys_fork+0x24/0x2c)
[<80016cd4>] (sys_fork) from [<8000a520>] (ret_fast_syscall+0x0/0x4c)
Code: eb001f58 e2505000 0a000017 e594b004 (e59b9000)
---[ end trace 6680cdd56c4514b7 ]---

Re: [PATCH 4.14 00/14] 4.14.230-rc1 review

[Guenter Roeck]

On Fri, Apr 09, 2021 at 01:13:06PM -0700, Guenter Roeck wrote:
> On Fri, Apr 09, 2021 at 11:53:25AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.230 release.
> > There are 14 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 Sun, 11 Apr 2021 09:52:52 +0000.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
> 	total: 168 pass: 168 fail: 0
> Qemu test results:
> 	total: 408 pass: 408 fail: 0
> 
> Tested-by: Guenter Roeck <linux@roeck-us.net>
> 
> Having said this, I did see a spurious crash, and I see an unusual warning.
> I have seen the crash only once, but the warning happens with every boot.
> These are likely not new but exposed because I added network interface
> tests. This is all v4.14.y specific; I did not see it in other branches.
> See below for the tracebacks. Maybe someone has seen it before.
> 
> Thanks,
> Guenter
> 
> ---
> ftgmac100 1e660000.ethernet eth0: NCSI interface down
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 477 at drivers/base/dma-mapping.c:325 remap_allocator_free+0x54/0x5c
> trying to free invalid coherent area: 909a1000
> Modules linked in:
> CPU: 0 PID: 477 Comm: ip Not tainted 4.14.230-rc1-00015-gbbc0ac1df344 #1
> Hardware name: Generic DT based system
> [<8000f8dc>] (unwind_backtrace) from [<8000d194>] (show_stack+0x10/0x14)
> [<8000d194>] (show_stack) from [<805a5a80>] (__warn+0xc0/0xf4)
> [<805a5a80>] (__warn) from [<800177b4>] (warn_slowpath_fmt+0x38/0x48)
> [<800177b4>] (warn_slowpath_fmt) from [<80010554>] (remap_allocator_free+0x54/0x5c)
> [<80010554>] (remap_allocator_free) from [<80010e4c>] (__arm_dma_free.constprop.0+0xec/0x13c)
> [<80010e4c>] (__arm_dma_free.constprop.0) from [<80429924>] (ftgmac100_free_rings+0x17c/0x1f8)
> [<80429924>] (ftgmac100_free_rings) from [<80429a24>] (ftgmac100_stop+0x84/0xa4)
> [<80429a24>] (ftgmac100_stop) from [<804e8a70>] (__dev_close_many+0xac/0x100)
> [<804e8a70>] (__dev_close_many) from [<804f0dc0>] (__dev_change_flags+0xb4/0x1a0)
> [<804f0dc0>] (__dev_change_flags) from [<804f0ec4>] (dev_change_flags+0x18/0x48)
> [<804f0ec4>] (dev_change_flags) from [<80561644>] (devinet_ioctl+0x6cc/0x808)
> [<80561644>] (devinet_ioctl) from [<804d1548>] (sock_ioctl+0x188/0x2e4)
> [<804d1548>] (sock_ioctl) from [<800eac80>] (do_vfs_ioctl+0x3a0/0x82c)
> [<800eac80>] (do_vfs_ioctl) from [<800eb140>] (SyS_ioctl+0x34/0x60)
> [<800eb140>] (SyS_ioctl) from [<8000a600>] (ret_fast_syscall+0x0/0x28)
> ---[ end trace c13f2f82f69274ad ]---
> 
> =====
> 
> ftgmac100 1e660000.ethernet eth0: NCSI interface up
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = 9ec84000
> [00000000] *pgd=9f7f6831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 17 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 397 Comm: default.script Not tainted 4.14.230-rc1-00015-gbbc0ac1df344 #1
> Hardware name: Generic DT based system
> task: 9f5cc260 task.stack: 9ecee000
> PC is at anon_vma_clone+0x64/0x19c
> LR is at fs_reclaim_release+0x8/0x18
> pc : [<800c1ccc>]    lr : [<80098b5c>]    psr: a0000153
> sp : 9ecefe78  ip : 00000000  fp : ffffffff
> r10: 01000200  r9 : 9f7e6d10  r8 : 80cb9a44
> r7 : 9f7e0da0  r6 : 9f7e6d10  r5 : 9ed0f600  r4 : 9f5a562c
> r3 : 00000030  r2 : 9fbdf618  r1 : 00000034  r0 : 9ed0f600
> Flags: NzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment user
> Control: 00c5387d  Table: 9ec84008  DAC: 00000055
> Process default.script (pid: 397, stack limit = 0x9ecee188)
> Stack: (0x9ecefe78 to 0x9ecf0000)
> fe60:                                                       9f5a303c 9f5a3000
> fe80: 00000002 9f7e0da0 9f7e0ab4 9f5a3000 9f77e600 9f7e0da0 9f5a3000 9f77e400
> fea0: 9f72dc64 800c1e28 9f7e0ab0 9f7e0ab4 00000002 9f77e600 9f7e0da0 800161f8
> fec0: 9f5cc640 cacd966c 9f5cc260 cd397f94 80cb0afc 00000000 80016870 00000000
> fee0: 00000000 9f69f2f8 9f7e0aa8 807ca224 9f7e0aa0 9f72dc70 9f69f100 00000011
> ff00: 9f77e658 9f77e458 9eceff08 9eceff08 9f5cc650 00000011 7eb26888 00000000
> ff20: 00000000 00000000 9ecee000 00000000 76eff3a0 80016870 00000000 00000000
> ff40: ffffffff 7eb26888 9eceff78 00000000 9ecee000 76ec4a28 7eb26888 9eceff78
> ff60: 00000000 7eb26888 00000008 00000000 00000008 800245e4 76efdcd0 7eb26888
> ff80: 00000000 00000002 8000a704 9ecee000 00000000 80016cd4 00000000 00000000
> ffa0: 9ecee000 8000a520 76efdcd0 7eb26888 76efffcc 00000001 76efe7ac 00000000
> ffc0: 76efdcd0 7eb26888 00000000 00000002 7eb26918 76efe000 76f00c60 76eff3a0
> ffe0: 000e0350 7eb26888 76e96b94 76e96b98 60000150 76efffcc 00000000 00000000
> [<800c1ccc>] (anon_vma_clone) from [<800c1e28>] (anon_vma_fork+0x24/0x138)
> [<800c1e28>] (anon_vma_fork) from [<800161f8>] (copy_process.part.0+0x12a4/0x17dc)
> [<800161f8>] (copy_process.part.0) from [<80016870>] (_do_fork+0xa0/0x488)
> [<80016870>] (_do_fork) from [<80016cd4>] (sys_fork+0x24/0x2c)
> [<80016cd4>] (sys_fork) from [<8000a520>] (ret_fast_syscall+0x0/0x4c)
> Code: eb001f58 e2505000 0a000017 e594b004 (e59b9000)
> ---[ end trace 6680cdd56c4514b7 ]---
> 

Hmm, turns out those are a bit more severe than I thought. The fix for both
the crash and the warning is commit 062b3e1b6d4f ("net/ncsi: Refactor MAC,
VLAN filters"). Unfortunately, that commit does not apply on its own.
The following sequence of commits on top of v4.14.y fixes the problem
for me.

5a6d80034471 net/ncsi: Make local function ncsi_get_filter() static
9ef8690be13d net/ncsi: Improve general state logging
04bad8bda9e2 net/ncsi: Don't return error on normal response
955dc68cb9b2 net/ncsi: Add generic netlink family
062b3e1b6d4f net/ncsi: Refactor MAC, VLAN filters

Guenter

Re: [PATCH 4.14 00/14] 4.14.230-rc1 review

[Naresh Kamboju]

On Fri, 9 Apr 2021 at 15:27, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.14.230 release.
> There are 14 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 Sun, 11 Apr 2021 09:52:52 +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.14.230-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.14.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.

Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>

## Build
* kernel: 4.14.230-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-4.14.y
* git commit: bbc0ac1df3446fb814abe1f0486c72f81bb95577
* git describe: v4.14.229-15-gbbc0ac1df344
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.229-15-gbbc0ac1df344

## No regressions (compared to v4.14.229)

## No fixes (compared to v4.14.229)


## Test result summary
 total: 54655, pass: 45540, fail: 651, skip: 8277, xfail: 187,

## Build Summary
* arm: 96 total, 96 passed, 0 failed
* arm64: 23 total, 23 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 13 total, 13 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 36 total, 36 passed, 0 failed
* sparc: 9 total, 9 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 13 total, 13 passed, 0 failed

## Test suites summary
* fwts
* igt-gpu-tools
* install-android-platform-tools-r2600
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-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-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance

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

Re: [PATCH 4.14 00/14] 4.14.230-rc1 review

[Naresh Kamboju]

On Sat, 10 Apr 2021 at 01:43, Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Fri, Apr 09, 2021 at 11:53:25AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.230 release.
> > There are 14 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 Sun, 11 Apr 2021 09:52:52 +0000.
> > Anything received after that time might be too late.
> >
>
> Build results:
>         total: 168 pass: 168 fail: 0
> Qemu test results:
>         total: 408 pass: 408 fail: 0
>
> Tested-by: Guenter Roeck <linux@roeck-us.net>
>
> Having said this, I did see a spurious crash, and I see an unusual warning.
> I have seen the crash only once, but the warning happens with every boot.
> These are likely not new but exposed because I added network interface
> tests. This is all v4.14.y specific; I did not see it in other branches.
> See below for the tracebacks. Maybe someone has seen it before.

I do not notice these warnings.
Please share the testing environment / device / setup / network interfaces
and Kernel configs and steps to reproduce.

 - Naresh

Re: [PATCH 4.14 00/14] 4.14.230-rc1 review

[Greg Kroah-Hartman]

On Fri, Apr 09, 2021 at 01:13:06PM -0700, Guenter Roeck wrote:
> On Fri, Apr 09, 2021 at 11:53:25AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.230 release.
> > There are 14 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 Sun, 11 Apr 2021 09:52:52 +0000.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
> 	total: 168 pass: 168 fail: 0
> Qemu test results:
> 	total: 408 pass: 408 fail: 0
> 
> Tested-by: Guenter Roeck <linux@roeck-us.net>
> 
> Having said this, I did see a spurious crash, and I see an unusual warning.
> I have seen the crash only once, but the warning happens with every boot.
> These are likely not new but exposed because I added network interface
> tests. This is all v4.14.y specific; I did not see it in other branches.
> See below for the tracebacks. Maybe someone has seen it before.

Thanks for testing all of these, I'll go queue up your reported fixes
here for the next release.

greg k-h

Re: [PATCH 4.14 00/14] 4.14.230-rc1 review

[Guenter Roeck]

Hi Greg,

On 4/10/21 6:15 AM, Greg Kroah-Hartman wrote:
> On Fri, Apr 09, 2021 at 01:13:06PM -0700, Guenter Roeck wrote:
>> On Fri, Apr 09, 2021 at 11:53:25AM +0200, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 4.14.230 release.
>>> There are 14 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 Sun, 11 Apr 2021 09:52:52 +0000.
>>> Anything received after that time might be too late.
>>>
>>
>> Build results:
>> 	total: 168 pass: 168 fail: 0
>> Qemu test results:
>> 	total: 408 pass: 408 fail: 0
>>
>> Tested-by: Guenter Roeck <linux@roeck-us.net>
>>
>> Having said this, I did see a spurious crash, and I see an unusual warning.
>> I have seen the crash only once, but the warning happens with every boot.
>> These are likely not new but exposed because I added network interface
>> tests. This is all v4.14.y specific; I did not see it in other branches.
>> See below for the tracebacks. Maybe someone has seen it before.
> 
> Thanks for testing all of these, I'll go queue up your reported fixes
> here for the next release.
> 

You'll need one more patch to avoid yet another warning:

b0949618826c net/ncsi: Avoid GFP_KERNEL in response handler

Thanks,
Guenter

Re: [PATCH 4.14 00/14] 4.14.230-rc1 review

[Guenter Roeck]

[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]

On 4/10/21 2:21 AM, Naresh Kamboju wrote:
> On Sat, 10 Apr 2021 at 01:43, Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On Fri, Apr 09, 2021 at 11:53:25AM +0200, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 4.14.230 release.
>>> There are 14 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 Sun, 11 Apr 2021 09:52:52 +0000.
>>> Anything received after that time might be too late.
>>>
>>
>> Build results:
>>         total: 168 pass: 168 fail: 0
>> Qemu test results:
>>         total: 408 pass: 408 fail: 0
>>
>> Tested-by: Guenter Roeck <linux@roeck-us.net>
>>
>> Having said this, I did see a spurious crash, and I see an unusual warning.
>> I have seen the crash only once, but the warning happens with every boot.
>> These are likely not new but exposed because I added network interface
>> tests. This is all v4.14.y specific; I did not see it in other branches.
>> See below for the tracebacks. Maybe someone has seen it before.
> 
> I do not notice these warnings.
> Please share the testing environment / device / setup / network interfaces
> and Kernel configs and steps to reproduce.
> 
>  - Naresh
> 

Hi Naresh,

the configuration is based on aspeed_g5_defconfig (see attached configuration file)
and the following qemu command line (qemu v5.2):

qemu-system-arm -M romulus-bmc -kernel \
	arch/arm/boot/zImage -no-reboot \
	-initrd rootfs-armv5.cpio -nic user -nodefaults \
	--append "panic=-1 slub_debug=FZPUA rdinit=/sbin/init console=ttyS4,115200 earlycon=uart8250,mmio32,0x1e784000,115200n8" \
	-dtb arch/arm/boot/dts/aspeed-bmc-opp-romulus.dtb \
	-nographic -monitor null -serial stdio

It also happens with other bmc platforms using the same network interface, though
it is for some reason more prevalent on romulus-bmc.

The root file system is generated with buildroot. See buildone.sh / buildall.sh
in branch local-2021.02 of git@github.com:groeck/buildroot.git. The warning happens
with almost every boot; the crash in maybe one of 5-10 boots. The test, if you want
to call it that, uses udhcpc to get an IP address and then

net_test_successful=0
ifconfig eth0 2>/dev/null | grep -q "inet addr:10.0.2.15"
if [ $? -eq 0 ]; then
    ping -q -c 1 -s 1000 -W 1 -I eth0 10.0.2.2 >/dev/null
    if [ $? -eq 0 ]; then
	telnet 10.0.2.2:22 </dev/null >/dev/null 2>dev/null
	if [ $? -eq 0 ]; then
	    net_test_successful=1
	fi
    fi
fi

See package/busybox/run.sh in the above repository/branch.

Guenter

[-- Attachment #2: defconfig.gz --]
[-- Type: application/gzip, Size: 1554 bytes --]