The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y
git checkout FETCH_HEAD
git cherry-pick -x 680d11f6e5427b6af1321932286722d24a8b16c1
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024042920-overcoat-cannot-efc1@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^..
Possible dependencies:
680d11f6e542 ("udp: preserve the connected status if only UDP cmsg")
5298953e742d ("udp6: don't make extra copies of iflow")
42dcfd850e51 ("udp6: allow SO_MARK ctrl msg to affect routing")
3df98d79215a ("lsm,selinux: pass flowi_common instead of flowi to the LSM hooks")
e94ee171349d ("xfrm: Use correct address family in xfrm_state_find")
5eff06902394 ("ipv4: fill fl4_icmp_{type,code} in ping_v4_sendmsg")
6abde0b24122 ("crypto/chtls: IPv6 support for inline TLS")
ed52f2c608c9 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 680d11f6e5427b6af1321932286722d24a8b16c1 Mon Sep 17 00:00:00 2001
From: Yick Xie <yick.xie(a)gmail.com>
Date: Fri, 19 Apr 2024 01:06:10 +0800
Subject: [PATCH] udp: preserve the connected status if only UDP cmsg
If "udp_cmsg_send()" returned 0 (i.e. only UDP cmsg),
"connected" should not be set to 0. Otherwise it stops
the connected socket from using the cached route.
Fixes: 2e8de8576343 ("udp: add gso segment cmsg")
Signed-off-by: Yick Xie <yick.xie(a)gmail.com>
Cc: stable(a)vger.kernel.org
Reviewed-by: Willem de Bruijn <willemb(a)google.com>
Link: https://lore.kernel.org/r/20240418170610.867084-1-yick.xie@gmail.com
Signed-off-by: Jakub Kicinski <kuba(a)kernel.org>
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index c02bf011d4a6..420905be5f30 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1123,16 +1123,17 @@ int udp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
if (msg->msg_controllen) {
err = udp_cmsg_send(sk, msg, &ipc.gso_size);
- if (err > 0)
+ if (err > 0) {
err = ip_cmsg_send(sk, msg, &ipc,
sk->sk_family == AF_INET6);
+ connected = 0;
+ }
if (unlikely(err < 0)) {
kfree(ipc.opt);
return err;
}
if (ipc.opt)
free = 1;
- connected = 0;
}
if (!ipc.opt) {
struct ip_options_rcu *inet_opt;
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 8b1dd7f51249..1a4cccdd40c9 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1474,9 +1474,11 @@ int udpv6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
ipc6.opt = opt;
err = udp_cmsg_send(sk, msg, &ipc6.gso_size);
- if (err > 0)
+ if (err > 0) {
err = ip6_datagram_send_ctl(sock_net(sk), sk, msg, fl6,
&ipc6);
+ connected = false;
+ }
if (err < 0) {
fl6_sock_release(flowlabel);
return err;
@@ -1488,7 +1490,6 @@ int udpv6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
}
if (!(opt->opt_nflen|opt->opt_flen))
opt = NULL;
- connected = false;
}
if (!opt) {
opt = txopt_get(np);
commit 475747a19316b08e856c666a20503e73d7ed67ed upstream.
Omit rx_use_md_dst comment in upstream commit since macsec_ops is not
documented.
Cannot know whether a Rx skb missing md_dst is intended for MACsec or not
without knowing whether the device is able to update this field during an
offload. Assume that an offload to a MACsec device cannot support updating
md_dst by default. Capable devices can advertise that they do indicate that
an skb is related to a MACsec offloaded packet using the md_dst.
Cc: Sabrina Dubroca <sd(a)queasysnail.net>
Cc: stable(a)vger.kernel.org
Fixes: 860ead89b851 ("net/macsec: Add MACsec skb_metadata_dst Rx Data path support")
Signed-off-by: Rahul Rameshbabu <rrameshbabu(a)nvidia.com>
Reviewed-by: Benjamin Poirier <bpoirier(a)nvidia.com>
Reviewed-by: Cosmin Ratiu <cratiu(a)nvidia.com>
Reviewed-by: Sabrina Dubroca <sd(a)queasysnail.net>
Link: https://lore.kernel.org/r/20240423181319.115860-2-rrameshbabu@nvidia.com
Signed-off-by: Jakub Kicinski <kuba(a)kernel.org>
---
include/net/macsec.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/net/macsec.h b/include/net/macsec.h
index 65c93959c2dc..dd578d193f9a 100644
--- a/include/net/macsec.h
+++ b/include/net/macsec.h
@@ -302,6 +302,7 @@ struct macsec_ops {
int (*mdo_get_tx_sa_stats)(struct macsec_context *ctx);
int (*mdo_get_rx_sc_stats)(struct macsec_context *ctx);
int (*mdo_get_rx_sa_stats)(struct macsec_context *ctx);
+ bool rx_uses_md_dst;
};
void macsec_pn_wrapped(struct macsec_secy *secy, struct macsec_tx_sa *tx_sa);
--
2.42.0
On Tue, Apr 30, 2024 at 01:20:27PM +0530, Atishya Jain wrote:
> XDP is used for Fast Packet Processing which is only on the RX path of the
> kernel . XDP on TX path is not supported by the kernel .
> Mail list for egress XDP : (Add Support of egress XDP patch )
If you rely on external changes, please work with the developers of
those changes, nothing we can do about them.
> So I Extracted the patch from it and first Applied on the latest Version
> only but got many failed to patch messages so I looked for different
> versions and 5.4 got matched almost perfectly .
Again, 5.4 is VERY old, and probably is doing something wrong with the
efi stuff that your system is expecting. Please try a more modern
kernel version please.
good luck!
greg k-h
This reverts commit 1d6cd2146c2b58bc91266db1d5d6a5f9632e14c0 which was
mistakenly added into v6.6.y and the commit corresponding to the 'Fixes:'
tag is invalid. For more information, see link [1].
This will result in the loss of Crashkernel data in /proc/iomem, and kdump
failed:
```
Memory for crashkernel is not reserved
Please reserve memory by passing"crashkernel=Y@X" parameter to kernel
Then try to loading kdump kernel
```
After revert, kdump works fine. Tested on QEMU riscv.
Link: https://lore.kernel.org/linux-riscv/ZSiQRDGLZk7lpakE@MiWiFi-R3L-srv [1]
Cc: Baoquan He <bhe(a)redhat.com>
Cc: Chen Jiahao <chenjiahao16(a)huawei.com>
Signed-off-by: Mingzheng Xing <xingmingzheng(a)iscas.ac.cn>
---
v1 -> v2:
- Changed the commit message
- Added Cc:
v1:
https://lore.kernel.org/stable/20240416085647.14376-1-xingmingzheng@iscas.a…
arch/riscv/kernel/setup.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index aac853ae4eb74..e600aab116a40 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -173,6 +173,19 @@ static void __init init_resources(void)
if (ret < 0)
goto error;
+#ifdef CONFIG_KEXEC_CORE
+ if (crashk_res.start != crashk_res.end) {
+ ret = add_resource(&iomem_resource, &crashk_res);
+ if (ret < 0)
+ goto error;
+ }
+ if (crashk_low_res.start != crashk_low_res.end) {
+ ret = add_resource(&iomem_resource, &crashk_low_res);
+ if (ret < 0)
+ goto error;
+ }
+#endif
+
#ifdef CONFIG_CRASH_DUMP
if (elfcorehdr_size > 0) {
elfcorehdr_res.start = elfcorehdr_addr;
--
2.34.1
Dear Linux Stable Team,
I am writing to report an issue encountered while attempting to boot kernel
version 5.4.274 with an egress XDP patch applied. The issue arises with the
EFI loader signature, leading to subsequent kernel panic.
*Problem Description:*
When attempting to boot kernel version 5.4.274 with the egress XDP patch, I
encountered the following sequence of events:
1. Initially, the system displays the message "Wrong EFI loader signature."
2. Following this message, the system proceeds to decompress the Linux
kernel and performs ELF parsing and relocations successfully.
3. However, upon attempting to boot the kernel, a kernel panic occurs with
the error message: "Kernel panic not syncing: UFS: Unable to mount root fs
on unknown-block(0,0)."
*Error Messages*:(ScreenShots Attached)
Upon selecting the kernel version 5.4.274, the system displays the
following error messages:
```
Wrong EFI loader signature.
early console in extract_kernel input_data: 0x00000000027493b1
input_len: 0x000000000086892c
output: 0x0000000001000000
output_len: 0x0000000001f81298
kernel_total_size: 0x0000000001e2c000
needed_size: 0x0000000002000000
trampoline_32bit: 0x0000000000090000
booted via startup_32()
Physical, KASLR using RDTSC. Virtual KASLR using RDTSC..
Decompressing Linux... Parsing ELF... Performing relocations... done.
Booting the kernel.
8.0522441 RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to
RETBleed attacks, data leaks possible!
0.9972031 Kernel panic not syncing: UFS: Unable to mount root fs on
unknown-block(0,0)
CPU: 1 PID: 1 Command: swapper/0 Not tainted 5.4.274 #1 Hardware name:
VMware, Inc. VMware Virtual Platform/440BX Desktop
Reference Platform, BIOS 6.00 11/12/2020
Call Trace:
dump_stack+0x58/0x63
panic+0x188/0x2ce
Mount_block_root+0x19b/0x23a
prepare_namespace+0x136/0x16c
kernel_init_freeable+0x207/0x210
rest_init+0x90/0x90
kernel_init+0x5/0xf6
ret_from_fork+0x35/0x48
Kernel Offset: 0x8488000 from 0xffffffff81000000 (relocation range:
0xffffffff80000000-0xfffffffffffffff) --- end Kernel panic not syncing:
UFS: Unable to mount root fs on unknown-block(0,8)
```
*Additional Information*:
- The issue persists even after signing the kernel.
- I am using Kali Linux in VMware, with the following system information:
- Linux kali 6.6.15-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.6.15-2kali1
(2024-04-09) x86_64 GNU/Linux
*Steps Taken*:
1. Applied egress XDP patch to kernel version 5.4.274.
2. Attempted to boot the patched kernel.
3. Encountered the "Wrong EFI loader signature" message followed by kernel
panic.
*Action Required*:
I kindly request assistance in resolving this issue or guidance on further
troubleshooting steps.
Please let me know if any additional information is required.
Thank you for your attention to this matter.
Best regards,
Atishya Jain
Project Associate
Indian Institute of Technology Gandhinagar
Palaj, Gandhinagar - 382055 - India.
Email: atishya.jain(a)iitgn.ac.in
LinkedIn: www.linkedin.com/in/atishya-jain-it
*Screenshots:*
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 720a22fd6c1cdadf691281909950c0cbc5cdf17e
Gitweb: https://git.kernel.org/tip/720a22fd6c1cdadf691281909950c0cbc5cdf17e
Author: Thomas Gleixner <tglx(a)linutronix.de>
AuthorDate: Fri, 26 Apr 2024 00:30:36 +02:00
Committer: Ingo Molnar <mingo(a)kernel.org>
CommitterDate: Tue, 30 Apr 2024 07:51:34 +02:00
x86/apic: Don't access the APIC when disabling x2APIC
With 'iommu=off' on the kernel command line and x2APIC enabled by the BIOS
the code which disables the x2APIC triggers an unchecked MSR access error:
RDMSR from 0x802 at rIP: 0xffffffff94079992 (native_apic_msr_read+0x12/0x50)
This is happens because default_acpi_madt_oem_check() selects an x2APIC
driver before the x2APIC is disabled.
When the x2APIC is disabled because interrupt remapping cannot be enabled
due to 'iommu=off' on the command line, x2apic_disable() invokes
apic_set_fixmap() which in turn tries to read the APIC ID. This triggers
the MSR warning because x2APIC is disabled, but the APIC driver is still
x2APIC based.
Prevent that by adding an argument to apic_set_fixmap() which makes the
APIC ID read out conditional and set it to false from the x2APIC disable
path. That's correct as the APIC ID has already been read out during early
discovery.
Fixes: d10a904435fa ("x86/apic: Consolidate boot_cpu_physical_apicid initialization sites")
Reported-by: Adrian Huang <ahuang12(a)lenovo.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de>
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Tested-by: Adrian Huang <ahuang12(a)lenovo.com>
Cc: stable(a)vger.kernel.org
Link: https://lore.kernel.org/r/875xw5t6r7.ffs@tglx
---
arch/x86/kernel/apic/apic.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index c342c4a..803dcfb 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1771,7 +1771,7 @@ void x2apic_setup(void)
__x2apic_enable();
}
-static __init void apic_set_fixmap(void);
+static __init void apic_set_fixmap(bool read_apic);
static __init void x2apic_disable(void)
{
@@ -1793,7 +1793,12 @@ static __init void x2apic_disable(void)
}
__x2apic_disable();
- apic_set_fixmap();
+ /*
+ * Don't reread the APIC ID as it was already done from
+ * check_x2apic() and the APIC driver still is a x2APIC variant,
+ * which fails to do the read after x2APIC was disabled.
+ */
+ apic_set_fixmap(false);
}
static __init void x2apic_enable(void)
@@ -2057,13 +2062,14 @@ void __init init_apic_mappings(void)
}
}
-static __init void apic_set_fixmap(void)
+static __init void apic_set_fixmap(bool read_apic)
{
set_fixmap_nocache(FIX_APIC_BASE, mp_lapic_addr);
apic_mmio_base = APIC_BASE;
apic_printk(APIC_VERBOSE, "mapped APIC to %16lx (%16lx)\n",
apic_mmio_base, mp_lapic_addr);
- apic_read_boot_cpu_id(false);
+ if (read_apic)
+ apic_read_boot_cpu_id(false);
}
void __init register_lapic_address(unsigned long address)
@@ -2073,7 +2079,7 @@ void __init register_lapic_address(unsigned long address)
mp_lapic_addr = address;
if (!x2apic_mode)
- apic_set_fixmap();
+ apic_set_fixmap(true);
}
/*