Hi,
I see a number of build failures in v4.19.y.queue.
Building arm:allmodconfig ... failed
--------------
drivers/memory/atmel-sdramc.c: In function 'atmel_ramc_probe':
drivers/memory/atmel-sdramc.c:62:23: error: implicit declaration of function 'devm_clk_get_enabled'
Building arm:imx_v6_v7_defconfig ... failed
--------------
Error log:
drivers/mmc/host/sdhci-esdhc-imx.c: In function 'sdhci_esdhc_imx_hwinit':
drivers/mmc/host/sdhci-esdhc-imx.c:1187:31: error: implicit declaration of function 'cqhci_readl'
drivers/mmc/host/sdhci-esdhc-imx.c:1187:52: error: 'CQHCI_IS' undeclared (first use in this function)
1187 | tmp = cqhci_readl(cq_host, CQHCI_IS);
drivers/mmc/host/sdhci-esdhc-imx.c:1188:25: error: implicit declaration of function 'cqhci_writel'; did you mean 'sdhci_writel'? [-Werror=implicit-function-declaration]
1188 | cqhci_writel(cq_host, tmp, CQHCI_IS);
drivers/mmc/host/sdhci-esdhc-imx.c:1189:47: error: 'CQHCI_HALT' undeclared (first use in this function)
1189 | cqhci_writel(cq_host, CQHCI_HALT, CQHCI_CTL);
| ^~~~~~~~~~
drivers/mmc/host/sdhci-esdhc-imx.c:1189:59: error: 'CQHCI_CTL' undeclared (first use in this function)
1189 | cqhci_writel(cq_host, CQHCI_HALT, CQHCI_CTL);
Other builds fail with the same errors.
Guenter
From: Soenke Huster <soenke.huster(a)eknoes.de>
commit 3afee2118132e93e5f6fa636dfde86201a860ab3 upstream.
This event is just specified for SCO and eSCO link types.
On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR
of an existing LE connection, LE link type and a status that triggers the
second case of the packet processing a NULL pointer dereference happens,
as conn->link is NULL.
Signed-off-by: Soenke Huster <soenke.huster(a)eknoes.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com>
Signed-off-by: Ovidiu Panait <ovidiu.panait(a)eng.windriver.com>
---
This fixes "BUG: KASAN: use-after-free in sco_chan_del()" issue detected while
fuzzing with syzkaller.
net/bluetooth/hci_event.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 57bf05253e04..685f89516e1e 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -4116,6 +4116,19 @@ static void hci_sync_conn_complete_evt(struct hci_dev *hdev,
struct hci_ev_sync_conn_complete *ev = (void *) skb->data;
struct hci_conn *conn;
+ switch (ev->link_type) {
+ case SCO_LINK:
+ case ESCO_LINK:
+ break;
+ default:
+ /* As per Core 5.3 Vol 4 Part E 7.7.35 (p.2219), Link_Type
+ * for HCI_Synchronous_Connection_Complete is limited to
+ * either SCO or eSCO
+ */
+ bt_dev_err(hdev, "Ignoring connect complete event for invalid link type");
+ return;
+ }
+
BT_DBG("%s status 0x%2.2x", hdev->name, ev->status);
hci_dev_lock(hdev);
--
2.23.0
From: Dave Hansen <dave.hansen(a)intel.com>
commit e400ad8b7e6a1b9102123c6240289a811501f7d9 upstream.
Old, circa 2002 chipsets have a bug: they don't go idle when they are
supposed to. So, a workaround was added to slow the CPU down and
ensure that the CPU waits a bit for the chipset to actually go idle.
This workaround is ancient and has been in place in some form since
the original kernel ACPI implementation.
But, this workaround is very painful on modern systems. The "inl()"
can take thousands of cycles (see Link: for some more detailed
numbers and some fun kernel archaeology).
First and foremost, modern systems should not be using this code.
Typical Intel systems have not used it in over a decade because it is
horribly inferior to MWAIT-based idle.
Despite this, people do seem to be tripping over this workaround on
AMD system today.
Limit the "dummy wait" workaround to Intel systems. Keep Modern AMD
systems from tripping over the workaround. Remotely modern Intel
systems use intel_idle instead of this code and will, in practice,
remain unaffected by the dummy wait.
Reported-by: K Prateek Nayak <kprateek.nayak(a)amd.com>
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak(a)amd.com>
Link: https://lore.kernel.org/all/20220921063638.2489-1-kprateek.nayak@amd.com/
Link: https://lkml.kernel.org/r/20220922184745.3252932-1-dave.hansen@intel.com
Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)igalia.com>
---
Hi folks, seems the intention was to send this to stable [0], so here it is,
lemme know if you see any issues with that - build tested in 5.10/5.15, also
it has been running for a while on Steam Deck's kernel.
Thanks,
Guilherme
[0] https://lore.kernel.org/stable/faa01372-07b0-3438-9305-123a3de9cc47@intel.c…
drivers/acpi/processor_idle.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index e5dd87ddc6b3..59781e765e0e 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -536,10 +536,27 @@ static void wait_for_freeze(void)
/* No delay is needed if we are in guest */
if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
return;
+ /*
+ * Modern (>=Nehalem) Intel systems use ACPI via intel_idle,
+ * not this code. Assume that any Intel systems using this
+ * are ancient and may need the dummy wait. This also assumes
+ * that the motivating chipset issue was Intel-only.
+ */
+ if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+ return;
#endif
- /* Dummy wait op - must do something useless after P_LVL2 read
- because chipsets cannot guarantee that STPCLK# signal
- gets asserted in time to freeze execution properly. */
+ /*
+ * Dummy wait op - must do something useless after P_LVL2 read
+ * because chipsets cannot guarantee that STPCLK# signal gets
+ * asserted in time to freeze execution properly
+ *
+ * This workaround has been in place since the original ACPI
+ * implementation was merged, circa 2002.
+ *
+ * If a profile is pointing to this instruction, please first
+ * consider moving your system to a more modern idle
+ * mechanism.
+ */
inl(acpi_gbl_FADT.xpm_timer_block.address);
}
--
2.39.0
While running xfstests on 4.14.304 version we see a warning being
generated in one of ext4 tests with the following stack trace.
WARNING: CPU: 4 PID: 15332 at mm/util.c:414
kvmalloc_node+0x67/0x70
ext4_expand_extra_isize_ea+0x2b4/0x870 [ext4]
__ext4_expand_extra_isize+0xcb/0x120 [ext4]
ext4_mark_inode_dirty+0x1a5/0x1d0 [ext4]
ext4_ext_truncate+0x1f/0x90 [ext4]
ext4_truncate+0x363/0x400 [ext4]
ext4_setattr+0x392/0xa00 [ext4]
notify_change+0x300/0x420
? ext4_xattr_security_set+0x20/0x20 [ext4]
do_truncate+0x75/0xc0
? ext4_release_file+0xa0/0xa0 [ext4]
path_openat+0x737/0x16f0
do_filp_open+0x9b/0x110
? __check_object_size+0xb4/0x190
? do_sys_open+0x1bd/0x250
do_sys_open+0x1bd/0x250
do_syscall_64+0x67/0x110
entry_SYSCALL_64_after_hwframe+0x59/0xbe
It seems rebase to 4.14.304 brings a bunch of ext4 changes.
Commit ext4: allocate extended attribute value in vmalloc area
(73c44f61dab180b5f2dee9f15397aba36a75a882) tries to allocate buffer
using kvmalloc with improper flags that generates this warning.
To fix backport an upstream commit mm: kvmalloc does not
fallback to vmalloc for incompatible gfp flags
(170f26afa0481c72af93aa61b7398b5663451651). This removes the WARN_ON and
fallsback to kmalloc if correct flags are not passed.
Michal Hocko (1):
mm: kvmalloc does not fallback to vmalloc for incompatible gfp flags
mm/util.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--
2.38.1