Hi Greg
6.4.10-rc1
compiles [1], boots and runs here on x86_64
(Intel Rocket Lake, i5-11400)
[1]
But I'm unable to compile vbox external modules anymore
seems to be a regression against Kernel 6.4.9
- WERROR is not set
- GDS_FORCE_MITIGATION=y
- new microcode is on the box
Error Message
=============
...
/tmp/vbox.0/linux/VBoxNetFlt-linux.c: In function
‘vboxNetFltLinuxForwardToIntNetInner’:
/tmp/vbox.0/linux/VBoxNetFlt-linux.c:1570:40: error: implicit
declaration of function ‘skb_gso_segment’; did you mean ‘skb_gso_reset’?
[-Werror=implicit-functio
n-declaration]
1570 | struct sk_buff *pSegment = skb_gso_segment(pBuf, 0
/*supported features*/);
| ^~~~~~~~~~~~~~~
| skb_gso_reset
/tmp/vbox.0/linux/VBoxNetFlt-linux.c:1570:40: warning: initialization of
‘struct sk_buff *’ from ‘int’ makes pointer from integer without a cast
[-Wint-conversi
on]
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:252:
/tmp/vbox.0/linux/VBoxNetFlt-linux.o] Error 1
make[1]: *** [Makefile:2032: /tmp/vbox.0] Error 2
make: *** [/tmp/vbox.0/Makefile-footer.gmk:133: vboxnetflt] Error 2
Thanks
Tested-by: Ronald Warsow <rwarsow(a)gmx.de>
DC*co/5/6 is not supported on DSI ports active in video mode (Bspec
4234, 49193).
On GLK for DSI command mode the "Enter/Exit Low Power Mode" sequence
would need to be programmed around each frame update (Bspec 21356) and
presumedly the same is required on BXT and SKL, even though it's not
stated for those explicitly (BXT: Bspec 13756). The driver doesn't run
these sequences, but command mode on BXT-GLK is not implemented either.
On ICL+ for DSI command mode DC*co/DSI is supported by the HW (Bspec
49195), but this is not implemented in the driver.
Based on the above disable DC states while DSI ports are active.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8419
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
---
drivers/gpu/drm/i915/display/intel_display_power_map.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index 5ad04cd42c158..1950dae4a7649 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -331,6 +331,7 @@ I915_DECL_PW_DOMAINS(skl_pwdoms_pw_2,
I915_DECL_PW_DOMAINS(skl_pwdoms_dc_off,
SKL_PW_2_POWER_DOMAINS,
+ POWER_DOMAIN_PORT_DSI,
POWER_DOMAIN_AUX_A,
POWER_DOMAIN_MODESET,
POWER_DOMAIN_GT_IRQ,
@@ -435,6 +436,7 @@ I915_DECL_PW_DOMAINS(bxt_pwdoms_pw_2,
I915_DECL_PW_DOMAINS(bxt_pwdoms_dc_off,
BXT_PW_2_POWER_DOMAINS,
+ POWER_DOMAIN_PORT_DSI,
POWER_DOMAIN_AUX_A,
POWER_DOMAIN_GMBUS,
POWER_DOMAIN_MODESET,
@@ -517,6 +519,7 @@ I915_DECL_PW_DOMAINS(glk_pwdoms_pw_2,
I915_DECL_PW_DOMAINS(glk_pwdoms_dc_off,
GLK_PW_2_POWER_DOMAINS,
+ POWER_DOMAIN_PORT_DSI,
POWER_DOMAIN_AUX_A,
POWER_DOMAIN_GMBUS,
POWER_DOMAIN_MODESET,
@@ -684,6 +687,7 @@ I915_DECL_PW_DOMAINS(icl_pwdoms_pw_2,
I915_DECL_PW_DOMAINS(icl_pwdoms_dc_off,
ICL_PW_2_POWER_DOMAINS,
+ POWER_DOMAIN_PORT_DSI,
POWER_DOMAIN_AUX_A,
POWER_DOMAIN_MODESET,
POWER_DOMAIN_DC_OFF,
@@ -858,6 +862,7 @@ I915_DECL_PW_DOMAINS(tgl_pwdoms_pw_2,
I915_DECL_PW_DOMAINS(tgl_pwdoms_dc_off,
TGL_PW_3_POWER_DOMAINS,
+ POWER_DOMAIN_PORT_DSI,
POWER_DOMAIN_AUX_A,
POWER_DOMAIN_AUX_B,
POWER_DOMAIN_AUX_C,
@@ -1056,6 +1061,7 @@ I915_DECL_PW_DOMAINS(rkl_pwdoms_pw_3,
I915_DECL_PW_DOMAINS(rkl_pwdoms_dc_off,
RKL_PW_3_POWER_DOMAINS,
+ POWER_DOMAIN_PORT_DSI,
POWER_DOMAIN_AUX_A,
POWER_DOMAIN_AUX_B,
POWER_DOMAIN_MODESET,
@@ -1138,6 +1144,7 @@ I915_DECL_PW_DOMAINS(dg1_pwdoms_pw_3,
I915_DECL_PW_DOMAINS(dg1_pwdoms_dc_off,
DG1_PW_3_POWER_DOMAINS,
+ POWER_DOMAIN_PORT_DSI,
POWER_DOMAIN_AUDIO_MMIO,
POWER_DOMAIN_AUX_A,
POWER_DOMAIN_AUX_B,
--
2.37.2
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 38f7c44d6e760a8513557e27340d61b820c91b8f
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023081127-cargo-stash-6a41@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^..
Possible dependencies:
38f7c44d6e76 ("selftests: forwarding: Set default IPv6 traceroute utility")
fe32dffdcd33 ("selftests: forwarding: add TCPDUMP_EXTRA_FLAGS to lib.sh")
b343734ee265 ("selftests: forwarding: add option to run tests with stable MAC addresses")
016748961ba5 ("selftests: lib: forwarding: allow tests to not require mz and jq")
0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev")
8cd6b020b644 ("selftests: ocelot: add some example VCAP IS1, IS2 and ES0 tc offloads")
6e701c299469 ("MAINTAINERS: merge entries for felix and ocelot drivers")
4400b7d68f6e ("MAINTAINERS: sort entries by entry name")
f365ab31efac ("Merge tag 'drm-next-2020-04-01' of git://anongit.freedesktop.org/drm/drm")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 38f7c44d6e760a8513557e27340d61b820c91b8f Mon Sep 17 00:00:00 2001
From: Ido Schimmel <idosch(a)nvidia.com>
Date: Tue, 8 Aug 2023 17:14:51 +0300
Subject: [PATCH] selftests: forwarding: Set default IPv6 traceroute utility
The test uses the 'TROUTE6' environment variable to encode the name of
the IPv6 traceroute utility. By default (without a configuration file),
this variable is not set, resulting in failures:
# ./ip6_forward_instats_vrf.sh
TEST: ping6 [ OK ]
TEST: Ip6InTooBigErrors [ OK ]
TEST: Ip6InHdrErrors [FAIL]
TEST: Ip6InAddrErrors [ OK ]
TEST: Ip6InDiscards [ OK ]
Fix by setting a default utility name and skip the test if the utility
is not present.
Fixes: 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev")
Reported-by: Mirsad Todorovac <mirsad.todorovac(a)alu.unizg.hr>
Closes: https://lore.kernel.org/netdev/adc5e40d-d040-a65e-eb26-edf47dac5b02@alu.uni…
Signed-off-by: Ido Schimmel <idosch(a)nvidia.com>
Reviewed-by: Petr Machata <petrm(a)nvidia.com>
Tested-by: Mirsad Todorovac <mirsad.todorovac(a)alu.unizg.hr>
Reviewed-by: Hangbin Liu <liuhangbin(a)gmail.com>
Acked-by: Nikolay Aleksandrov <razor(a)blackwall.org>
Link: https://lore.kernel.org/r/20230808141503.4060661-6-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba(a)kernel.org>
diff --git a/tools/testing/selftests/net/forwarding/ip6_forward_instats_vrf.sh b/tools/testing/selftests/net/forwarding/ip6_forward_instats_vrf.sh
index 9f5b3e2e5e95..49fa94b53a1c 100755
--- a/tools/testing/selftests/net/forwarding/ip6_forward_instats_vrf.sh
+++ b/tools/testing/selftests/net/forwarding/ip6_forward_instats_vrf.sh
@@ -14,6 +14,8 @@ ALL_TESTS="
NUM_NETIFS=4
source lib.sh
+require_command $TROUTE6
+
h1_create()
{
simple_if_init $h1 2001:1:1::2/64
diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
index 975fc5168c63..40a8c1541b7f 100755
--- a/tools/testing/selftests/net/forwarding/lib.sh
+++ b/tools/testing/selftests/net/forwarding/lib.sh
@@ -30,6 +30,7 @@ REQUIRE_MZ=${REQUIRE_MZ:=yes}
REQUIRE_MTOOLS=${REQUIRE_MTOOLS:=no}
STABLE_MAC_ADDRS=${STABLE_MAC_ADDRS:=no}
TCPDUMP_EXTRA_FLAGS=${TCPDUMP_EXTRA_FLAGS:=}
+TROUTE6=${TROUTE6:=traceroute6}
relative_path="${BASH_SOURCE%/*}"
if [[ "$relative_path" == "${BASH_SOURCE}" ]]; then
The patch below does not apply to the 5.10-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.10.y
git checkout FETCH_HEAD
git cherry-pick -x 38f7c44d6e760a8513557e27340d61b820c91b8f
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023081125-finicky-impromptu-4126@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^..
Possible dependencies:
38f7c44d6e76 ("selftests: forwarding: Set default IPv6 traceroute utility")
fe32dffdcd33 ("selftests: forwarding: add TCPDUMP_EXTRA_FLAGS to lib.sh")
b343734ee265 ("selftests: forwarding: add option to run tests with stable MAC addresses")
016748961ba5 ("selftests: lib: forwarding: allow tests to not require mz and jq")
0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 38f7c44d6e760a8513557e27340d61b820c91b8f Mon Sep 17 00:00:00 2001
From: Ido Schimmel <idosch(a)nvidia.com>
Date: Tue, 8 Aug 2023 17:14:51 +0300
Subject: [PATCH] selftests: forwarding: Set default IPv6 traceroute utility
The test uses the 'TROUTE6' environment variable to encode the name of
the IPv6 traceroute utility. By default (without a configuration file),
this variable is not set, resulting in failures:
# ./ip6_forward_instats_vrf.sh
TEST: ping6 [ OK ]
TEST: Ip6InTooBigErrors [ OK ]
TEST: Ip6InHdrErrors [FAIL]
TEST: Ip6InAddrErrors [ OK ]
TEST: Ip6InDiscards [ OK ]
Fix by setting a default utility name and skip the test if the utility
is not present.
Fixes: 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev")
Reported-by: Mirsad Todorovac <mirsad.todorovac(a)alu.unizg.hr>
Closes: https://lore.kernel.org/netdev/adc5e40d-d040-a65e-eb26-edf47dac5b02@alu.uni…
Signed-off-by: Ido Schimmel <idosch(a)nvidia.com>
Reviewed-by: Petr Machata <petrm(a)nvidia.com>
Tested-by: Mirsad Todorovac <mirsad.todorovac(a)alu.unizg.hr>
Reviewed-by: Hangbin Liu <liuhangbin(a)gmail.com>
Acked-by: Nikolay Aleksandrov <razor(a)blackwall.org>
Link: https://lore.kernel.org/r/20230808141503.4060661-6-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba(a)kernel.org>
diff --git a/tools/testing/selftests/net/forwarding/ip6_forward_instats_vrf.sh b/tools/testing/selftests/net/forwarding/ip6_forward_instats_vrf.sh
index 9f5b3e2e5e95..49fa94b53a1c 100755
--- a/tools/testing/selftests/net/forwarding/ip6_forward_instats_vrf.sh
+++ b/tools/testing/selftests/net/forwarding/ip6_forward_instats_vrf.sh
@@ -14,6 +14,8 @@ ALL_TESTS="
NUM_NETIFS=4
source lib.sh
+require_command $TROUTE6
+
h1_create()
{
simple_if_init $h1 2001:1:1::2/64
diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
index 975fc5168c63..40a8c1541b7f 100755
--- a/tools/testing/selftests/net/forwarding/lib.sh
+++ b/tools/testing/selftests/net/forwarding/lib.sh
@@ -30,6 +30,7 @@ REQUIRE_MZ=${REQUIRE_MZ:=yes}
REQUIRE_MTOOLS=${REQUIRE_MTOOLS:=no}
STABLE_MAC_ADDRS=${STABLE_MAC_ADDRS:=no}
TCPDUMP_EXTRA_FLAGS=${TCPDUMP_EXTRA_FLAGS:=}
+TROUTE6=${TROUTE6:=traceroute6}
relative_path="${BASH_SOURCE%/*}"
if [[ "$relative_path" == "${BASH_SOURCE}" ]]; then
The patch below does not apply to the 5.15-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.15.y
git checkout FETCH_HEAD
git cherry-pick -x 7588dbcebcbf0193ab5b76987396d0254270b04a
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023081107-secluding-shed-defa@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^..
Possible dependencies:
7588dbcebcbf ("KVM: SEV: only access GHCB fields once")
4e15a0ddc3ff ("KVM: SEV: snapshot the GHCB before accessing it")
aa9f58415a8e ("KVM: SVM: Exit to userspace on ENOMEM/EFAULT GHCB errors")
ad5b353240c8 ("KVM: SVM: Do not terminate SEV-ES guests on GHCB validation failure")
a655276a5949 ("KVM: SEV: Fall back to vmalloc for SEV-ES scratch area if necessary")
75236f5f2299 ("KVM: SEV: Return appropriate error codes if SEV-ES scratch setup fails")
1f05833193d8 ("Merge branch 'kvm-sev-move-context' into kvm-master")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 7588dbcebcbf0193ab5b76987396d0254270b04a Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <pbonzini(a)redhat.com>
Date: Fri, 4 Aug 2023 12:56:36 -0400
Subject: [PATCH] KVM: SEV: only access GHCB fields once
A KVM guest using SEV-ES or SEV-SNP with multiple vCPUs can trigger
a double fetch race condition vulnerability and invoke the VMGEXIT
handler recursively.
sev_handle_vmgexit() maps the GHCB page using kvm_vcpu_map() and then
fetches the exit code using ghcb_get_sw_exit_code(). Soon after,
sev_es_validate_vmgexit() fetches the exit code again. Since the GHCB
page is shared with the guest, the guest is able to quickly swap the
values with another vCPU and hence bypass the validation. One vmexit code
that can be rejected by sev_es_validate_vmgexit() is SVM_EXIT_VMGEXIT;
if sev_handle_vmgexit() observes it in the second fetch, the call
to svm_invoke_exit_handler() will invoke sev_handle_vmgexit() again
recursively.
To avoid the race, always fetch the GHCB data from the places where
sev_es_sync_from_ghcb stores it.
Exploiting recursions on linux kernel has been proven feasible
in the past, but the impact is mitigated by stack guard pages
(CONFIG_VMAP_STACK). Still, if an attacker manages to call the handler
multiple times, they can theoretically trigger a stack overflow and
cause a denial-of-service, or potentially guest-to-host escape in kernel
configurations without stack guard pages.
Note that winning the race reliably in every iteration is very tricky
due to the very tight window of the fetches; depending on the compiler
settings, they are often consecutive because of optimization and inlining.
Tested by booting an SEV-ES RHEL9 guest.
Fixes: CVE-2023-4155
Fixes: 291bd20d5d88 ("KVM: SVM: Add initial support for a VMGEXIT VMEXIT")
Cc: stable(a)vger.kernel.org
Reported-by: Andy Nguyen <theflow(a)google.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index e898f0b2b0ba..ca4ba5fe9a01 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -2445,9 +2445,15 @@ static void sev_es_sync_from_ghcb(struct vcpu_svm *svm)
memset(ghcb->save.valid_bitmap, 0, sizeof(ghcb->save.valid_bitmap));
}
+static u64 kvm_ghcb_get_sw_exit_code(struct vmcb_control_area *control)
+{
+ return (((u64)control->exit_code_hi) << 32) | control->exit_code;
+}
+
static int sev_es_validate_vmgexit(struct vcpu_svm *svm)
{
- struct kvm_vcpu *vcpu;
+ struct vmcb_control_area *control = &svm->vmcb->control;
+ struct kvm_vcpu *vcpu = &svm->vcpu;
struct ghcb *ghcb;
u64 exit_code;
u64 reason;
@@ -2458,7 +2464,7 @@ static int sev_es_validate_vmgexit(struct vcpu_svm *svm)
* Retrieve the exit code now even though it may not be marked valid
* as it could help with debugging.
*/
- exit_code = ghcb_get_sw_exit_code(ghcb);
+ exit_code = kvm_ghcb_get_sw_exit_code(control);
/* Only GHCB Usage code 0 is supported */
if (ghcb->ghcb_usage) {
@@ -2473,7 +2479,7 @@ static int sev_es_validate_vmgexit(struct vcpu_svm *svm)
!kvm_ghcb_sw_exit_info_2_is_valid(svm))
goto vmgexit_err;
- switch (ghcb_get_sw_exit_code(ghcb)) {
+ switch (exit_code) {
case SVM_EXIT_READ_DR7:
break;
case SVM_EXIT_WRITE_DR7:
@@ -2490,18 +2496,18 @@ static int sev_es_validate_vmgexit(struct vcpu_svm *svm)
if (!kvm_ghcb_rax_is_valid(svm) ||
!kvm_ghcb_rcx_is_valid(svm))
goto vmgexit_err;
- if (ghcb_get_rax(ghcb) == 0xd)
+ if (vcpu->arch.regs[VCPU_REGS_RAX] == 0xd)
if (!kvm_ghcb_xcr0_is_valid(svm))
goto vmgexit_err;
break;
case SVM_EXIT_INVD:
break;
case SVM_EXIT_IOIO:
- if (ghcb_get_sw_exit_info_1(ghcb) & SVM_IOIO_STR_MASK) {
+ if (control->exit_info_1 & SVM_IOIO_STR_MASK) {
if (!kvm_ghcb_sw_scratch_is_valid(svm))
goto vmgexit_err;
} else {
- if (!(ghcb_get_sw_exit_info_1(ghcb) & SVM_IOIO_TYPE_MASK))
+ if (!(control->exit_info_1 & SVM_IOIO_TYPE_MASK))
if (!kvm_ghcb_rax_is_valid(svm))
goto vmgexit_err;
}
@@ -2509,7 +2515,7 @@ static int sev_es_validate_vmgexit(struct vcpu_svm *svm)
case SVM_EXIT_MSR:
if (!kvm_ghcb_rcx_is_valid(svm))
goto vmgexit_err;
- if (ghcb_get_sw_exit_info_1(ghcb)) {
+ if (control->exit_info_1) {
if (!kvm_ghcb_rax_is_valid(svm) ||
!kvm_ghcb_rdx_is_valid(svm))
goto vmgexit_err;
@@ -2553,8 +2559,6 @@ static int sev_es_validate_vmgexit(struct vcpu_svm *svm)
return 0;
vmgexit_err:
- vcpu = &svm->vcpu;
-
if (reason == GHCB_ERR_INVALID_USAGE) {
vcpu_unimpl(vcpu, "vmgexit: ghcb usage %#x is not valid\n",
ghcb->ghcb_usage);
@@ -2852,8 +2856,6 @@ int sev_handle_vmgexit(struct kvm_vcpu *vcpu)
trace_kvm_vmgexit_enter(vcpu->vcpu_id, ghcb);
- exit_code = ghcb_get_sw_exit_code(ghcb);
-
sev_es_sync_from_ghcb(svm);
ret = sev_es_validate_vmgexit(svm);
if (ret)
@@ -2862,6 +2864,7 @@ int sev_handle_vmgexit(struct kvm_vcpu *vcpu)
ghcb_set_sw_exit_info_1(ghcb, 0);
ghcb_set_sw_exit_info_2(ghcb, 0);
+ exit_code = kvm_ghcb_get_sw_exit_code(control);
switch (exit_code) {
case SVM_VMGEXIT_MMIO_READ:
ret = setup_vmgexit_scratch(svm, true, control->exit_info_2);
I'm announcing the release of the 5.15.126 kernel.
All users of the 5.15 kernel series must upgrade.
The updated 5.15.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.15.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Alan Stern (1):
net: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urb
Aleksa Sarai (1):
open: make RESOLVE_CACHED correctly test for O_TMPFILE
Alexander Stein (1):
drm/imx/ipuv3: Fix front porch adjustment upon hactive aligning
Alexandra Winter (1):
s390/qeth: Don't call dev_close/dev_open (DOWN/UP)
Aneesh Kumar K.V (1):
powerpc/mm/altmap: Fix altmap boundary check
Arseniy Krasnov (1):
mtd: rawnand: meson: fix OOB available bytes for ECC
Benjamin Poirier (1):
vxlan: Fix nexthop hash size
Borislav Petkov (AMD) (1):
x86/CPU/AMD: Do not leak quotient data after a division by 0
Chengfeng Ye (1):
mISDN: hfcpci: Fix potential deadlock on &hc->lock
Christophe JAILLET (1):
mtd: rawnand: fsl_upm: Fix an off-by one test in fun_exec_op()
Chunfeng Yun (1):
PM / wakeirq: support enabling wake-up irq after runtime_suspend called
Dan Carpenter (1):
net: ll_temac: fix error checking of irq_of_parse_and_map()
Dinh Nguyen (1):
arm64: dts: stratix10: fix incorrect I2C property for SCL signal
Eric Dumazet (12):
net: annotate data-races around sk->sk_max_pacing_rate
net: add missing READ_ONCE(sk->sk_rcvlowat) annotation
net: add missing READ_ONCE(sk->sk_sndbuf) annotation
net: add missing READ_ONCE(sk->sk_rcvbuf) annotation
net: add missing data-race annotations around sk->sk_peek_off
net: add missing data-race annotation for sk_ll_usec
tcp_metrics: fix addr_same() helper
tcp_metrics: annotate data-races around tm->tcpm_stamp
tcp_metrics: annotate data-races around tm->tcpm_lock
tcp_metrics: annotate data-races around tm->tcpm_vals[]
tcp_metrics: annotate data-races around tm->tcpm_net
tcp_metrics: fix data-race in tcpm_suck_dst() vs fastopen
Georg Müller (1):
perf test uprobe_from_different_cu: Skip if there is no gcc
Greg Kroah-Hartman (1):
Linux 5.15.126
Guchun Chen (1):
drm/ttm: check null pointer before accessing when swapping
Heiko Carstens (1):
KVM: s390: fix sthyi error handling
Hou Tao (2):
bpf, cpumap: Handle skb as well when clean up ptr_ring
bpf, cpumap: Make sure kthread is running before map update returns
Hugo Villeneuve (1):
arm64: dts: imx8mn-var-som: add missing pull-up for onboard PHY reset pinmux
Ilan Peer (1):
wifi: cfg80211: Fix return value in scan logic
Ilya Dryomov (2):
libceph: fix potential hang in ceph_osdc_notify()
rbd: prevent busy loop when requesting exclusive lock
Jamal Hadi Salim (1):
net: sched: cls_u32: Fix match key mis-addressing
Jan Kara (2):
fs: Protect reconfiguration of sb read-write from racing writes
ext2: Drop fragment support
Jens Axboe (1):
io_uring: gate iowait schedule on having pending requests
Jianbo Liu (2):
net/mlx5: fs_core: Make find_closest_ft more generic
net/mlx5: fs_core: Skip the FTs in the same FS_TYPE_PRIO_CHAINS fs_prio
Jiri Olsa (1):
bpf: Disable preemption in bpf_event_output
Johan Hovold (2):
soundwire: fix enumeration completion
PM: sleep: wakeirq: fix wake irq arming
Johan Jonker (2):
mtd: rawnand: rockchip: fix oobfree offset and description
mtd: rawnand: rockchip: Align hwecc vs. raw page helper layouts
Jonas Gorski (1):
prestera: fix fallback to previous version on same major version
Konstantin Khorenko (1):
qed: Fix scheduling in a tasklet while getting stats
Krzysztof Kozlowski (1):
firmware: arm_scmi: Drop OF node reference in the transport channel setup
Kuniyuki Iwashima (1):
net/sched: taprio: Limit TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME to INT_MAX.
Laszlo Ersek (2):
net: tun_chr_open(): set sk_uid from current_fsuid()
net: tap_open(): set sk_uid from current_fsuid()
Lin Ma (3):
bpf: Add length check for SK_DIAG_BPF_STORAGE_REQ_MAP_FD parsing
rtnetlink: let rtnl_bridge_setlink checks IFLA_BRIDGE_MODE length
net: dcb: choose correct policy to parse DCB_ATTR_BCN
Linus Torvalds (1):
file: reinstate f_pos locking optimization for regular files
Mark Brown (1):
net: netsec: Ignore 'phy-mode' on SynQuacer in DT mode
Michael Jeanson (1):
selftests/rseq: check if libc rseq support is registered
Michael Kelley (1):
scsi: storvsc: Limit max_sectors for virtual Fibre Channel devices
Olivier Maignial (1):
mtd: spinand: toshiba: Fix ecc_get_status
Paul Fertser (1):
wifi: mt76: mt7615: do not advertise 5 GHz on first phy of MT7615D (DBDC)
Peter Zijlstra (1):
perf: Fix function pointer case
Pierre-Louis Bossart (1):
soundwire: bus: pm_runtime_request_resume on peripheral attachment
Prabhakar Kushwaha (1):
qed: Fix kernel-doc warnings
Prince Kumar Maurya (1):
fs/sysv: Null check to prevent null-ptr-deref bug
Robin Murphy (4):
iommu/arm-smmu-v3: Work around MMU-600 erratum 1076982
iommu/arm-smmu-v3: Document MMU-700 erratum 2812531
iommu/arm-smmu-v3: Add explicit feature for nesting
iommu/arm-smmu-v3: Document nesting-related errata
Roger Quadros (1):
mtd: rawnand: omap_elm: Fix incorrect type in assignment
Ross Maynard (1):
USB: zaurus: Add ID for A-300/B-500/C-700
Sean Christopherson (1):
selftests/rseq: Play nice with binaries statically linked against glibc 2.35+
Shay Drory (1):
net/mlx5: Free irqs only on shutdown callback
Steffen Maier (1):
scsi: zfcp: Defer fc_rport blocking until after ADISC response
Sungjong Seo (1):
exfat: release s_lock before calling dir_emit()
Sungwoo Kim (1):
Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_ready_cb
Suzuki K Poulose (2):
arm64: errata: Add workaround for TSB flush failures
arm64: errata: Add detection for TRBE write to out-of-range
Tetsuo Handa (1):
fs/ntfs3: Use __GFP_NOWARN allocation at ntfs_load_attr_list()
Tomas Glozar (1):
bpf: sockmap: Remove preempt_disable in sock_map_sk_acquire
Xiubo Li (1):
ceph: defer stopping mdsc delayed_work
Yang Yingliang (1):
net: ll_temac: Switch to use dev_err_probe() helper
Yuanjun Gong (3):
net/mlx5e: fix return value check in mlx5e_ipsec_remove_trailer()
net: dsa: fix value check in bcm_sf2_sw_probe()
net: korina: handle clk prepare error in korina_probe()
Yue Haibing (1):
ip6mr: Fix skb_under_panic in ip6mr_cache_report()
Zhengchao Shao (1):
net/mlx5: DR, fix memory leak in mlx5dr_cmd_create_reformat_ctx
gaoming (1):
exfat: use kvmalloc_array/kvfree instead of kmalloc_array/kfree
ndesaulniers(a)google.com (1):
word-at-a-time: use the same return type for has_zero regardless of endianness
valis (3):
net/sched: cls_u32: No longer copy tcf_result on update to avoid use-after-free
net/sched: cls_fw: No longer copy tcf_result on update to avoid use-after-free
net/sched: cls_route: No longer copy tcf_result on update to avoid use-after-free
LKFT build plans updated with toolchain gcc-13 and here is the report.
Stable rc 6.1 arm64 builds with gcc-13 failed and the bisection is pointing
to this as first bad commit,
# first fixed commit: [e6a71160cc145e18ab45195abf89884112e02dfb]
gcc-plugins: Reorganize gimple includes for GCC 13
Thanks Anders for bisecting this problem against Linux 6.2-rc6.
Build errors:
---------------
In file included from /builds/linux/scripts/gcc-plugins/gcc-common.h:75,
from /builds/linux/scripts/gcc-plugins/stackleak_plugin.c:30:
/usr/lib/gcc-cross/aarch64-linux-gnu/13/plugin/include/gimple-fold.h:72:32:
error: use of enum 'gsi_iterator_update' without previous declaration
72 | enum gsi_iterator_update,
| ^~~~~~~~~~~~~~~~~~
Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org>
Links:
--------
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y-sanity/build…
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y-sanity/build…
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y-sanity/build…
--
Linaro LKFT
https://lkft.linaro.org
The WinSystems WS16C48 I/O address region spans offsets 0x0 through 0xA,
which is a total of 11 bytes. Fix the WS16C48_EXTENT define to the
correct value of 11 so that access to necessary device registers is
properly requested in the ws16c48_probe() callback by the
devm_request_region() function call.
Fixes: 2c05a0f29f41 ("gpio: ws16c48: Implement and utilize register structures")
Cc: stable(a)vger.kernel.org
Cc: Paul Demetrotion <pdemetrotion(a)winsystems.com>
Signed-off-by: William Breathitt Gray <william.gray(a)linaro.org>
---
drivers/gpio/gpio-ws16c48.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-ws16c48.c b/drivers/gpio/gpio-ws16c48.c
index 701847508e94..6289b0510cf2 100644
--- a/drivers/gpio/gpio-ws16c48.c
+++ b/drivers/gpio/gpio-ws16c48.c
@@ -17,7 +17,7 @@
#include <linux/regmap.h>
#include <linux/types.h>
-#define WS16C48_EXTENT 10
+#define WS16C48_EXTENT 11
#define MAX_NUM_WS16C48 max_num_isa_dev(WS16C48_EXTENT)
static unsigned int base[MAX_NUM_WS16C48];
--
2.41.0
Hi Greg! Months ago you picked up mainline commit a2b6e99d8a6
("drm/i915: Disable DC states for all commits") for the 6.1.23 release
as commit 0fc6fea41c71. It causes issues vor a few people (at least
three, two of which are CCed) -- apparently because it depends on some
change that wasn't picked up for 6.1.y. This is known for a while now,
but nobody has yet found which change that is (Al found something that
worked for him, but that didn't work for others). For the whole story
skim this ticket:
https://gitlab.freedesktop.org/drm/intel/-/issues/8419
I wonder if it might be better if you revert that commit for 6.0.y; I
asked already in the ticket if this is likely to cause regressions for
users of 6.0.y, but got no answer from the i915 devs (or did I miss
something?). :-/
Ciao, Thorsten
From: Frederic Weisbecker <frederic(a)kernel.org>
[ Upstream commit a1ff03cd6fb9c501fff63a4a2bface9adcfa81cd ]
tick: Detect and fix jiffies update stall
On some rare cases, the timekeeper CPU may be delaying its jiffies
update duty for a while. Known causes include:
* The timekeeper is waiting on stop_machine in a MULTI_STOP_DISABLE_IRQ
or MULTI_STOP_RUN state. Disabled interrupts prevent from timekeeping
updates while waiting for the target CPU to complete its
stop_machine() callback.
* The timekeeper vcpu has VMEXIT'ed for a long while due to some overload
on the host.
Detect and fix these situations with emergency timekeeping catchups.
Original-patch-by: Paul E. McKenney <paulmck(a)kernel.org>
Signed-off-by: Frederic Weisbecker <frederic(a)kernel.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org>
---
kernel/time/tick-sched.c | 17 +++++++++++++++++
kernel/time/tick-sched.h | 4 ++++
2 files changed, 21 insertions(+)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index f42d0776bc84..7701c720dc1f 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -180,6 +180,8 @@ static ktime_t tick_init_jiffy_update(void)
return period;
}
+#define MAX_STALLED_JIFFIES 5
+
static void tick_sched_do_timer(struct tick_sched *ts, ktime_t now)
{
int cpu = smp_processor_id();
@@ -207,6 +209,21 @@ static void tick_sched_do_timer(struct tick_sched *ts, ktime_t now)
if (tick_do_timer_cpu == cpu)
tick_do_update_jiffies64(now);
+ /*
+ * If jiffies update stalled for too long (timekeeper in stop_machine()
+ * or VMEXIT'ed for several msecs), force an update.
+ */
+ if (ts->last_tick_jiffies != jiffies) {
+ ts->stalled_jiffies = 0;
+ ts->last_tick_jiffies = READ_ONCE(jiffies);
+ } else {
+ if (++ts->stalled_jiffies == MAX_STALLED_JIFFIES) {
+ tick_do_update_jiffies64(now);
+ ts->stalled_jiffies = 0;
+ ts->last_tick_jiffies = READ_ONCE(jiffies);
+ }
+ }
+
if (ts->inidle)
ts->got_idle_tick = 1;
}
diff --git a/kernel/time/tick-sched.h b/kernel/time/tick-sched.h
index d952ae393423..504649513399 100644
--- a/kernel/time/tick-sched.h
+++ b/kernel/time/tick-sched.h
@@ -49,6 +49,8 @@ enum tick_nohz_mode {
* @timer_expires_base: Base time clock monotonic for @timer_expires
* @next_timer: Expiry time of next expiring timer for debugging purpose only
* @tick_dep_mask: Tick dependency mask - is set, if someone needs the tick
+ * @last_tick_jiffies: Value of jiffies seen on last tick
+ * @stalled_jiffies: Number of stalled jiffies detected across ticks
*/
struct tick_sched {
struct hrtimer sched_timer;
@@ -77,6 +79,8 @@ struct tick_sched {
u64 next_timer;
ktime_t idle_expires;
atomic_t tick_dep_mask;
+ unsigned long last_tick_jiffies;
+ unsigned int stalled_jiffies;
};
extern struct tick_sched *tick_get_tick_sched(int cpu);
--
2.41.0.640.ga95def55d0-goog
For Wake-on-LAN to work from S5 (shutdown), the USB link must be put
in U3 state. If it is not, and the host "disappears", the chip will
no longer respond to WoL triggers.
To resolve this, add a notifier block and register it as a reboot
notifier. When WoL is enabled, work through the usb_device struct to
get to the suspend function. Calling this function puts the link in
the correct state for WoL to function.
Cc: stable(a)vger.kernel.org
Signed-off-by: Alexandru Gagniuc <alexandru.gagniuc(a)hp.com>
---
drivers/net/usb/r8152.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0999a58ca9d2..5623ca5c9142 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -20,6 +20,7 @@
#include <net/ip6_checksum.h>
#include <uapi/linux/mdio.h>
#include <linux/mdio.h>
+#include <linux/reboot.h>
#include <linux/usb/cdc.h>
#include <linux/suspend.h>
#include <linux/atomic.h>
@@ -875,6 +876,7 @@ struct r8152 {
struct delayed_work schedule, hw_phy_work;
struct mii_if_info mii;
struct mutex control; /* use for hw setting */
+ struct notifier_block reboot_notifier;
#ifdef CONFIG_PM_SLEEP
struct notifier_block pm_notifier;
#endif
@@ -9609,6 +9611,25 @@ static bool rtl8152_supports_lenovo_macpassthru(struct usb_device *udev)
return 0;
}
+/* Suspend realtek chip before system shutdown
+ *
+ * For Wake-on-LAN to work from S5, the USB link must be put in U3 state. If
+ * the host otherwise "disappears", the chip will not respond to WoL triggers.
+ */
+static int rtl8152_notify(struct notifier_block *nb, unsigned long code,
+ void *unused)
+{
+ struct r8152 *tp = container_of(nb, struct r8152, reboot_notifier);
+ struct device *dev = &tp->udev->dev;
+
+ if (code == SYS_POWER_OFF) {
+ if (tp->saved_wolopts && dev->type->pm->suspend)
+ dev->type->pm->suspend(dev);
+ }
+
+ return NOTIFY_DONE;
+}
+
static int rtl8152_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
@@ -9791,6 +9812,9 @@ static int rtl8152_probe(struct usb_interface *intf,
else
device_set_wakeup_enable(&udev->dev, false);
+ tp->reboot_notifier.notifier_call = rtl8152_notify;
+ register_reboot_notifier(&tp->reboot_notifier);
+
netif_info(tp, probe, netdev, "%s\n", DRIVER_VERSION);
return 0;
@@ -9811,6 +9835,7 @@ static void rtl8152_disconnect(struct usb_interface *intf)
if (tp) {
rtl_set_unplug(tp);
+ unregister_reboot_notifier(&tp->reboot_notifier);
unregister_netdev(tp->netdev);
tasklet_kill(&tp->tx_tl);
cancel_delayed_work_sync(&tp->hw_phy_work);
--
2.39.1
With recent changes necessitating mmap_lock to be held for write while
expanding a stack, per-VMA locks should follow the same rules and be
write-locked to prevent page faults into the VMA being expanded. Add
the necessary locking.
Cc: stable(a)vger.kernel.org
Signed-off-by: Suren Baghdasaryan <surenb(a)google.com>
---
mm/mmap.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/mm/mmap.c b/mm/mmap.c
index 204ddcd52625..c66e4622a557 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1977,6 +1977,8 @@ static int expand_upwards(struct vm_area_struct *vma, unsigned long address)
return -ENOMEM;
}
+ /* Lock the VMA before expanding to prevent concurrent page faults */
+ vma_start_write(vma);
/*
* vma->vm_start/vm_end cannot change under us because the caller
* is required to hold the mmap_lock in read mode. We need the
@@ -2064,6 +2066,8 @@ int expand_downwards(struct vm_area_struct *vma, unsigned long address)
return -ENOMEM;
}
+ /* Lock the VMA before expanding to prevent concurrent page faults */
+ vma_start_write(vma);
/*
* vma->vm_start/vm_end cannot change under us because the caller
* is required to hold the mmap_lock in read mode. We need the
--
2.41.0.390.g38632f3daf-goog
GDB uses /proc/PID/mem to access memory of the target process. GDB
doesn't untag addresses manually, but relies on kernel to do the right
thing.
mem_rw() of procfs uses access_remote_vm() to get data from the target
process. It worked fine until recent changes in __access_remote_vm()
that now checks if there's VMA at target address using raw address.
Untag the address before looking up the VMA.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Reported-by: Christina Schimpe <christina.schimpe(a)intel.com>
Fixes: eee9c708cc89 ("gup: avoid stack expansion warning for known-good case")
Cc: stable(a)vger.kernel.org
---
mm/memory.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index 01f39e8144ef..3be9db30db32 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -5701,6 +5701,9 @@ int __access_remote_vm(struct mm_struct *mm, unsigned long addr, void *buf,
if (mmap_read_lock_killable(mm))
return 0;
+ /* Untag the address before looking up the VMA */
+ addr = untagged_addr_remote(mm, addr);
+
/* Avoid triggering the temporary warning in __get_user_pages */
if (!vma_lookup(mm, addr) && !expand_stack(mm, addr))
return 0;
--
2.41.0
Hi,
The following patchset contains Netfilter fixes for net.
The existing attempt to resolve races between control plane and GC work
is error prone, as reported by Bien Pham <phamnnb(a)sea.com>, some places
forgot to call nft_set_elem_mark_busy(), leading to double-deactivation
of elements.
This series contains the following patches:
1) Do not skip expired elements during walk otherwise elements might
never decrement the reference counter on data, leading to memleak.
2) Add a GC transaction API to replace the former attempt to deal with
races between control plane and GC. GC worker sets on NFT_SET_ELEM_DEAD_BIT
on elements and it creates a GC transaction to remove the expired
elements, GC transaction could abort in case of interference with
control plane and retried later (GC async). Set backends such as
rbtree and pipapo also perform GC from control plane (GC sync), in
such case, element deactivation and removal is safe because mutex
is held then collected elements are released via call_rcu().
3) Adapt existing set backends to use the GC transaction API.
4) Update rhash set backend to set on _DEAD bit to report deleted
elements from datapath for GC.
5) Remove old GC batch API and the NFT_SET_ELEM_BUSY_BIT.
Florian Westphal (1):
netfilter: nf_tables: don't skip expired elements during walk
Pablo Neira Ayuso (4):
netfilter: nf_tables: GC transaction API to avoid race with control plane
netfilter: nf_tables: adapt set backend to use GC transaction API
netfilter: nft_set_hash: mark set element as dead when deleting from packet path
netfilter: nf_tables: remove busy mark and gc batch API
Please, pull these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git nf-23-08-10
Thanks.
----------------------------------------------------------------
The following changes since commit c5ccff70501d92db445a135fa49cf9bc6b98c444:
Merge branch 'net-sched-bind-logic-fixes-for-cls_fw-cls_u32-and-cls_route' (2023-07-31 20:10:39 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git tags/nf-23-08-10
for you to fetch changes up to a2dd0233cbc4d8a0abb5f64487487ffc9265beb5:
netfilter: nf_tables: remove busy mark and gc batch API (2023-08-10 08:25:27 +0200)
----------------------------------------------------------------
netfilter pull request 23-08-10
----------------------------------------------------------------
Florian Westphal (1):
netfilter: nf_tables: don't skip expired elements during walk
Pablo Neira Ayuso (4):
netfilter: nf_tables: GC transaction API to avoid race with control plane
netfilter: nf_tables: adapt set backend to use GC transaction API
netfilter: nft_set_hash: mark set element as dead when deleting from packet path
netfilter: nf_tables: remove busy mark and gc batch API
include/net/netfilter/nf_tables.h | 120 ++++++---------
net/netfilter/nf_tables_api.c | 307 ++++++++++++++++++++++++++++++--------
net/netfilter/nft_set_hash.c | 85 +++++++----
net/netfilter/nft_set_pipapo.c | 66 +++++---
net/netfilter/nft_set_rbtree.c | 146 ++++++++++--------
5 files changed, 476 insertions(+), 248 deletions(-)
When unloading the MANA driver, mana_dealloc_queues() waits for the MANA
hardware to complete any inflight packets and set the pending send count
to zero. But if the hardware has failed, mana_dealloc_queues()
could wait forever.
Fix this by adding a timeout to the wait. Set the timeout to 120 seconds,
which is a somewhat arbitrary value that is more than long enough for
functional hardware to complete any sends.
Cc: stable(a)vger.kernel.org
Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)")
Signed-off-by: Souradeep Chakrabarti <schakrabarti(a)linux.microsoft.com>
---
V7 -> V8:
* Replaced dev_consume_skb_any with dev_kfree_skb_any.
* Added extra braces to use assignment as truth value.
V6 -> V7:
* Optimized the while loop for freeing skb.
V5 -> V6:
* Added pcie_flr to reset the pci after timeout.
* Fixed the position of changelog.
* Removed unused variable like cq.
V4 -> V5:
* Added fixes tag
* Changed the usleep_range from static to incremental value.
* Initialized timeout in the begining.
V3 -> V4:
* Removed the unnecessary braces from mana_dealloc_queues().
V2 -> V3:
* Removed the unnecessary braces from mana_dealloc_queues().
V1 -> V2:
* Added net branch
* Removed the typecasting to (struct mana_context*) of void pointer
* Repositioned timeout variable in mana_dealloc_queues()
* Repositioned vf_unload_timeout in mana_context struct, to utilise the
6 bytes hole
---
drivers/net/ethernet/microsoft/mana/mana_en.c | 37 +++++++++++++++++--
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
index a499e460594b..c2ad0921e893 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_en.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
@@ -8,6 +8,7 @@
#include <linux/ethtool.h>
#include <linux/filter.h>
#include <linux/mm.h>
+#include <linux/pci.h>
#include <net/checksum.h>
#include <net/ip6_checksum.h>
@@ -2345,9 +2346,12 @@ int mana_attach(struct net_device *ndev)
static int mana_dealloc_queues(struct net_device *ndev)
{
struct mana_port_context *apc = netdev_priv(ndev);
+ unsigned long timeout = jiffies + 120 * HZ;
struct gdma_dev *gd = apc->ac->gdma_dev;
struct mana_txq *txq;
+ struct sk_buff *skb;
int i, err;
+ u32 tsleep;
if (apc->port_is_up)
return -EINVAL;
@@ -2363,15 +2367,40 @@ static int mana_dealloc_queues(struct net_device *ndev)
* to false, but it doesn't matter since mana_start_xmit() drops any
* new packets due to apc->port_is_up being false.
*
- * Drain all the in-flight TX packets
+ * Drain all the in-flight TX packets.
+ * A timeout of 120 seconds for all the queues is used.
+ * This will break the while loop when h/w is not responding.
+ * This value of 120 has been decided here considering max
+ * number of queues.
*/
+
for (i = 0; i < apc->num_queues; i++) {
txq = &apc->tx_qp[i].txq;
-
- while (atomic_read(&txq->pending_sends) > 0)
- usleep_range(1000, 2000);
+ tsleep = 1000;
+ while (atomic_read(&txq->pending_sends) > 0 &&
+ time_before(jiffies, timeout)) {
+ usleep_range(tsleep, tsleep + 1000);
+ tsleep <<= 1;
+ }
+ if (atomic_read(&txq->pending_sends)) {
+ err = pcie_flr(to_pci_dev(gd->gdma_context->dev));
+ if (err) {
+ netdev_err(ndev, "flr failed %d with %d pkts pending in txq %u\n",
+ err, atomic_read(&txq->pending_sends),
+ txq->gdma_txq_id);
+ }
+ break;
+ }
}
+ for (i = 0; i < apc->num_queues; i++) {
+ txq = &apc->tx_qp[i].txq;
+ while ((skb = skb_dequeue(&txq->pending_skbs))) {
+ mana_unmap_skb(skb, apc);
+ dev_kfree_skb_any(skb);
+ }
+ atomic_set(&txq->pending_sends, 0);
+ }
/* We're 100% sure the queues can no longer be woken up, because
* we're sure now mana_poll_tx_cq() can't be running.
*/
--
2.34.1
Hi Joe,
A recent mistake I made when using b4 was that I added a fixes tag,
but forgot to Cc: stable in the commit message.
Speaking with Konstantine, it seems that b4 may just be importing the
recommendations from get_maintainer.pl.
I suspect that either b4 or get_maintainer could see the Fixes tag and
then suggest to Cc stable for me.
Should get_maintainer.pl make such recommendations?
--
Thanks,
~Nick Desaulniers
variable *nplanes is provided by user via system call argument. The
possible value of q_data->fmt->num_planes is 1-3, while the value
of *nplanes can be 1-8. The array access by index i can cause array
out-of-bounds.
Fix this bug by checking *nplanes against the array size.
Fixes: 4e855a6efa54 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver")
Signed-off-by: Wei Chen <harperchen1110(a)gmail.com>
Cc: stable(a)vger.kernel.org
---
Changes in v2:
- Add Fixes tag and CC stable email address
- Change the title to be more expressive
drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c
index 9ff439a50f53..9e8817863cb8 100644
--- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c
@@ -821,6 +821,8 @@ static int vb2ops_venc_queue_setup(struct vb2_queue *vq,
return -EINVAL;
if (*nplanes) {
+ if (*nplanes != q_data->fmt->num_planes)
+ return -EINVAL;
for (i = 0; i < *nplanes; i++)
if (sizes[i] < q_data->sizeimage[i])
return -EINVAL;
--
2.25.1
Hi,
Just wanted to make sure you received my last email regarding a
customized list of Learning, Training, Talent Development, Corporate
Training etc contacts. I’m looking to find the right person who looks
after your prospecting and lead generation.
We help companies grow sales with our highly targeted email lists.
Please let us know your target industries and job titles so we can send
you the numbers of contacts.
Regards,
Julia
On Tue, 21-06-2023 11:43 AM, Julia Anderson wrote:
Hi,
Would you be interested in reaching out to top level decisions makers to
promote/sell your services?
Learning/Training/Talent Development
CVD Human Resource
CVD Learning
Corporate Training
Meeting & Events
Owners, CEO, Presidents etc
We would be happy to customize your list accordingly for any other
requirements that you have.
Industries:
Information Technology |Finance |Advertising & Marketing |Construction
and Real estate |Charity and NGO’s |Education |Publishing |Retail |
Consumer | Manufacturing |Government & public agencies |Electronics and
Telecommunications |Industry associations |Healthcare | Hospitality
|Legal Services |Food & Beverages |Media & Entertainment |Energy and
chemicals |Aerospace and Defense |Transportation and Logistics ETC.
Appreciate your response.
Regards,
Julia
Julia Anderson | Marketing Consultant
Reply only opt-out in the subject line to remove from the mailing list.
Hi ,
We are noticing the below warning in the latest 5.4.252 kernel bootup logs.
WARNING: CPU: 0 PID: 0 at arch/x86/kernel/fpu/xstate.c:878
get_xsave_addr+0x83/0x90
and relevant call trace in the logs , after updating to kernel 5.4.252.
I see that issue is due to this commit
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=…
This is seen in the qemu instance which is emulating the host cpu
and was deployed on Intel(R) Xeon(R) Gold 5218 processor.
I revert the commit and there is no WARNING and call trace in the logs
, Is this issue already reported and a fix is available? Could you
please provide your inputs.
Regards,
Rajesh.
From: Mark Brown <broonie(a)kernel.org>
[ upstream commit d5ad9aae13dcced333c1a7816ff0a4fbbb052466 ]
Commit 3bcbc20942db ("selftests/rseq: Play nice with binaries statically
linked against glibc 2.35+") which is now in Linus' tree introduced uses
of __weak but did nothing to ensure that a definition is provided for it
resulting in build failures for the rseq tests:
rseq.c:41:1: error: unknown type name '__weak'
__weak ptrdiff_t __rseq_offset;
^
rseq.c:41:17: error: expected ';' after top level declarator
__weak ptrdiff_t __rseq_offset;
^
;
rseq.c:42:1: error: unknown type name '__weak'
__weak unsigned int __rseq_size;
^
rseq.c:43:1: error: unknown type name '__weak'
__weak unsigned int __rseq_flags;
Fix this by using the definition from tools/include compiler.h.
Fixes: 3bcbc20942db ("selftests/rseq: Play nice with binaries statically linked against glibc 2.35+")
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Message-Id: <20230804-kselftest-rseq-build-v1-1-015830b66aa9(a)kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
---
tools/testing/selftests/rseq/Makefile | 4 +++-
tools/testing/selftests/rseq/rseq.c | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/rseq/Makefile b/tools/testing/selftests/rseq/Makefile
index b357ba24af06..7a957c7d459a 100644
--- a/tools/testing/selftests/rseq/Makefile
+++ b/tools/testing/selftests/rseq/Makefile
@@ -4,8 +4,10 @@ ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep clang),)
CLANG_FLAGS += -no-integrated-as
endif
+top_srcdir = ../../../..
+
CFLAGS += -O2 -Wall -g -I./ $(KHDR_INCLUDES) -L$(OUTPUT) -Wl,-rpath=./ \
- $(CLANG_FLAGS)
+ $(CLANG_FLAGS) -I$(top_srcdir)/tools/include
LDLIBS += -lpthread -ldl
# Own dependencies because we only want to build against 1st prerequisite, but
diff --git a/tools/testing/selftests/rseq/rseq.c b/tools/testing/selftests/rseq/rseq.c
index a723da253244..96e812bdf8a4 100644
--- a/tools/testing/selftests/rseq/rseq.c
+++ b/tools/testing/selftests/rseq/rseq.c
@@ -31,6 +31,8 @@
#include <sys/auxv.h>
#include <linux/auxvec.h>
+#include <linux/compiler.h>
+
#include "../kselftest.h"
#include "rseq.h"
--
2.41.0
This patch series enables support of i2c bus for Intel Alder Lake PCH-P and PCH-M
on kernel version 5.10. These patches add ID's of Alder lake platform in these
drivers: i801, intel-lpss, pinctrl. ID's were taken from linux kernel version 5.15.
Alexander Ofitserov (3):
i2c: i801: Add support for Intel Alder Lake PCH
mfd: intel-lpss: Add Alder Lake's PCI devices IDs
pinctrl: tigerlake: Add Alder Lake-P ACPI ID
drivers/i2c/busses/i2c-i801.c | 8 +++++
drivers/mfd/intel-lpss-pci.c | 41 +++++++++++++++++++++++
drivers/pinctrl/intel/pinctrl-tigerlake.c | 1 +
3 files changed, 50 insertions(+)
--
2.33.8
This patch series enables support of i2c bus for Intel Alder Lake PCH-P and PCH-M
on kernel version 5.10. These patches add ID's of Alder lake platform in these
drivers: i801, intel-lpss, pinctrl. ID's were taken from linux kernel version 5.15.
Alexander Ofitserov (3):
i2c: i801: Add support for Intel Alder Lake PCH
mfd: intel-lpss: Add Alder Lake's PCI devices IDs
pinctrl: tigerlake: Add Alder Lake-P ACPI ID
drivers/i2c/busses/i2c-i801.c | 8 +++++
drivers/mfd/intel-lpss-pci.c | 41 +++++++++++++++++++++++
drivers/pinctrl/intel/pinctrl-tigerlake.c | 1 +
3 files changed, 50 insertions(+)
--
2.33.8
Kernel uses `struct virtio_net_ctrl_rss` to save command-specific-data
for both the VIRTIO_NET_CTRL_MQ_HASH_CONFIG and
VIRTIO_NET_CTRL_MQ_RSS_CONFIG commands.
According to the VirtIO standard, "Field reserved MUST contain zeroes.
It is defined to make the structure to match the layout of
virtio_net_rss_config structure, defined in 5.1.6.5.7.".
Yet for the VIRTIO_NET_CTRL_MQ_HASH_CONFIG command case, the `max_tx_vq`
field in struct virtio_net_ctrl_rss, which corresponds to the
`reserved` field in struct virtio_net_hash_config, is not zeroed,
thereby violating the VirtIO standard.
This patch solves this problem by zeroing this field in
virtnet_init_default_rss().
Cc: Andrew Melnychenko <andrew(a)daynix.com>
Cc: stable(a)vger.kernel.org
Fixes: c7114b1249fa ("drivers/net/virtio_net: Added basic RSS support.")
Signed-off-by: Hawkins Jiawei <yin31149(a)gmail.com>
Acked-by: Jason Wang <jasowang(a)redhat.com>
Acked-by: Eugenio Pérez <eperezma(a)redhat.com>
Acked-by: Michael S. Tsirkin <mst(a)redhat.com>
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 1270c8d23463..8db38634ae82 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2761,7 +2761,7 @@ static void virtnet_init_default_rss(struct virtnet_info *vi)
vi->ctrl->rss.indirection_table[i] = indir_val;
}
- vi->ctrl->rss.max_tx_vq = vi->curr_queue_pairs;
+ vi->ctrl->rss.max_tx_vq = vi->has_rss ? vi->curr_queue_pairs : 0;
vi->ctrl->rss.hash_key_length = vi->rss_key_size;
netdev_rss_key_fill(vi->ctrl->rss.key, vi->rss_key_size);
--
2.34.1
The kernel hangs for a good 12 seconds without any info being printed to
dmesg, very early in the boot process, if this regulator is not enabled.
Force-enable it to work around this issue, until we know more about the
underlying problem.
Signed-off-by: Paul Cercueil <paul(a)crapouillou.net>
Fixes: 8620cc2f99b7 ("ARM: dts: exynos: Add devicetree file for the Galaxy S2")
Cc: <stable(a)vger.kernel.org> # v5.8+
---
arch/arm/boot/dts/exynos4210-i9100.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-i9100.dts b/arch/arm/boot/dts/exynos4210-i9100.dts
index a9ec1f6c1dea..a076a1dfe41f 100644
--- a/arch/arm/boot/dts/exynos4210-i9100.dts
+++ b/arch/arm/boot/dts/exynos4210-i9100.dts
@@ -527,6 +527,14 @@ vtcam_reg: LDO12 {
regulator-name = "VT_CAM_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
+
+ /*
+ * Force-enable this regulator; otherwise the
+ * kernel hangs very early in the boot process
+ * for about 12 seconds, without apparent
+ * reason.
+ */
+ regulator-always-on;
};
vcclcd_reg: LDO13 {
--
2.40.1
Hi All,
Here is v3 of my series to address the regressions wrt PS/2 IRQs
not working on AMD zen models.
Changes in v3:
- Add links to more bug reports caused by a9c4a912b7dc to the commitmsg
- Also do the ZEN check for IRQ 12 (Reported-by August Wikerfors)
- Move the gsi != 1 && gsi != 12 check to inside the #ifdef CONFIG_X86,
these being the i8042 IRQs is X86 specific and the "return true;" is
always done for #ifndef CONFIG_X86 already
- Make acpi_int_src_ovr an array which keep track of the status
of all legacy IRQs and not just IRQ 1
Changes in v2:
- Add 2 patches on top of the revert to avoid the revert causing
other models which are known to need the override to regress.
As discussed in the v1 thread:
https://lore.kernel.org/linux-acpi/20230806151453.10690-1-hdegoede@redhat.c…
This series adds a few fixes on top of the revert to avoid the revert
causing regressions on other AMD Zen systems where dropping the special
Zen behavior was known to fix things.
As also mentioned in the thread this is intended as a short term fix
for 6.4.y >= 6.4.7 and 6.5 to get all the systems which were working
fine before commit a9c4a912b7dc ("ACPI: resource: Remove "Zen"
specific match and quirks") to work again.
The long term plan is to see if we can read back what the BIOS
has actually programmed as IRQ trigger-type / polarity into
the IOAPIC.
Regards,
Hans
Hans de Goede (3):
ACPI: resource: revert "Remove "Zen" specific match and quirks"
ACPI: resource: Always use MADT override IRQ settings for all legacy
non i8042 IRQs
ACPI: resource: Honor MADT INT_SRC_OVR settings for IRQ1 on AMD Zen
arch/x86/include/asm/acpi.h | 2 ++
arch/x86/kernel/acpi/boot.c | 4 +++
drivers/acpi/resource.c | 52 +++++++++++++++++++++++++++++++++++++
3 files changed, 58 insertions(+)
--
2.41.0
Dzień dobry,
jakiś czas temu zgłosiła się do nas firma, której strona internetowa nie pozycjonowała się wysoko w wyszukiwarce Google.
Na podstawie wykonanego przez nas audytu SEO zoptymalizowaliśmy treści na stronie pod kątem wcześniej opracowanych słów kluczowych. Nasz wewnętrzny system codziennie analizuje prawidłowe działanie witryny. Dzięki indywidualnej strategii, firma zdobywa coraz więcej Klientów.
Czy chcieliby Państwo zwiększyć liczbę osób odwiedzających stronę internetową firmy? Mógłbym przedstawić ofertę?
Pozdrawiam serdecznie,
Dominik Perkowski
The dma-buf backend is supposed to provide its own vm_ops, but some
implementation just have nothing special to do and leave vm_ops
untouched, probably expecting this field to be zero initialized (this
is the case with the system_heap implementation for instance).
Let's reset vma->vm_ops to NULL to keep things working with these
implementations.
Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf")
Cc: <stable(a)vger.kernel.org>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Reported-by: Roman Stratiienko <roman.stratiienko(a)globallogic.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)collabora.com>
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 4ea6507a77e5..baaf0e0feb06 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -623,7 +623,13 @@ int drm_gem_shmem_mmap(struct drm_gem_shmem_object *shmem, struct vm_area_struct
int ret;
if (obj->import_attach) {
+ /* Reset both vm_ops and vm_private_data, so we don't end up with
+ * vm_ops pointing to our implementation if the dma-buf backend
+ * doesn't set those fields.
+ */
vma->vm_private_data = NULL;
+ vma->vm_ops = NULL;
+
ret = dma_buf_mmap(obj->dma_buf, vma, 0);
/* Drop the reference drm_gem_mmap_obj() acquired.*/
--
2.41.0
Can we backport this patch into stable? It fixes a build error with
binutils >= 2.41.
On Mon, 2023-07-10 at 13:00 +0800, Huacai Chen wrote:
> Binutils 2.41 enables linker relaxation by default, but the kernel
> module loader doesn't support that, so just disable it. Otherwise we
> get such an error when loading modules:
>
> "Unknown relocation type 102"
>
> As an alternative, we could add linker relaxation support in the kernel
> module loader. But it is relatively large complexity that may or may not
> bring a similar gain, and we don't really want to include this linker
> pass in the kernel.
>
> Reviewed-by: WANG Xuerui <git(a)xen0n.name>
> Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn>
> ---
> arch/loongarch/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
> index 09ba338a64de..7466d3b15db8 100644
> --- a/arch/loongarch/Makefile
> +++ b/arch/loongarch/Makefile
> @@ -68,6 +68,8 @@ LDFLAGS_vmlinux += -static -n -nostdlib
> ifdef CONFIG_AS_HAS_EXPLICIT_RELOCS
> cflags-y += $(call cc-option,-mexplicit-relocs)
> KBUILD_CFLAGS_KERNEL += $(call cc-option,-mdirect-extern-access)
> +KBUILD_AFLAGS_MODULE += $(call cc-option,-mno-relax) $(call cc-option,-Wa$(comma)-mno-relax)
> +KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-relax) $(call cc-option,-Wa$(comma)-mno-relax)
> else
> cflags-y += $(call cc-option,-mno-explicit-relocs)
> KBUILD_AFLAGS_KERNEL += -Wa,-mla-global-with-pcrel
--
Xi Ruoyao <xry111(a)xry111.site>
School of Aerospace Science and Technology, Xidian University
The bison and flex generate C files from the source (.y and .l)
files. When O= option is used, they are saved in a separate directory
but the default build rule assumes the .C files are in the source
directory. So it might read invalid file if there are generated files
from an old version. The same is true for the pmu-events files.
For example, the following command would cause a build failure:
$ git checkout v6.3
$ make -C tools/perf # build in the same directory
$ git checkout v6.5-rc2
$ mkdir build # create a build directory
$ make -C tools/perf O=build # build in a different directory but it
# refers files in the source directory
Let's update the build rule to specify those cases explicitly to depend
on the files in the output directory.
Note that it's not a complete fix and it needs the next patch for the
include path too.
Fixes: 80eeb67fe577 ("perf jevents: Program to convert JSON file")
Cc: stable(a)vger.kernel.org
Signed-off-by: Namhyung Kim <namhyung(a)kernel.org>
---
tools/build/Makefile.build | 10 ++++++++++
tools/perf/pmu-events/Build | 6 ++++++
2 files changed, 16 insertions(+)
diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
index 89430338a3d9..fac42486a8cf 100644
--- a/tools/build/Makefile.build
+++ b/tools/build/Makefile.build
@@ -117,6 +117,16 @@ $(OUTPUT)%.s: %.c FORCE
$(call rule_mkdir)
$(call if_changed_dep,cc_s_c)
+# bison and flex files are generated in the OUTPUT directory
+# so it needs a separate rule to depend on them properly
+$(OUTPUT)%-bison.o: $(OUTPUT)%-bison.c FORCE
+ $(call rule_mkdir)
+ $(call if_changed_dep,$(host)cc_o_c)
+
+$(OUTPUT)%-flex.o: $(OUTPUT)%-flex.c FORCE
+ $(call rule_mkdir)
+ $(call if_changed_dep,$(host)cc_o_c)
+
# Gather build data:
# obj-y - list of build objects
# subdir-y - list of directories to nest
diff --git a/tools/perf/pmu-events/Build b/tools/perf/pmu-events/Build
index 150765f2baee..1d18bb89402e 100644
--- a/tools/perf/pmu-events/Build
+++ b/tools/perf/pmu-events/Build
@@ -35,3 +35,9 @@ $(PMU_EVENTS_C): $(JSON) $(JSON_TEST) $(JEVENTS_PY) $(METRIC_PY) $(METRIC_TEST_L
$(call rule_mkdir)
$(Q)$(call echo-cmd,gen)$(PYTHON) $(JEVENTS_PY) $(JEVENTS_ARCH) $(JEVENTS_MODEL) pmu-events/arch $@
endif
+
+# pmu-events.c file is generated in the OUTPUT directory so it needs a
+# separate rule to depend on it properly
+$(OUTPUT)pmu-events/pmu-events.o: $(PMU_EVENTS_C)
+ $(call rule_mkdir)
+ $(call if_changed_dep,cc_o_c)
--
2.41.0.487.g6d72f3e995-goog
Hey Greg,
There was recently a bit of a snafoo with a maintainer taking the wrong
version of a patch and sending that up to Linus. That patch had
incorrect stable@ annotations and had a bug in it. That bug was fixed
with a follow up patch. But of course the metadata couldn't be changed
easily retroactively.
So I'm emailing to ask you to backport these two patches back to 5.5:
- 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs")
- cacc6e22932f ("tpm: Add a helper for checking hwrng enabled")
I know the stable@ tag says 6.1+, but the actual right tags from the
newer versioned patch that didn't get picked are:
Cc: stable(a)vger.kernel.org # 5.5+
Fixes: b006c439d58d ("hwrng: core - start hwrng kthread also for untrusted sources")
Fixes: f1324bbc4011 ("tpm: disable hwrng for fTPM on some AMD designs")
Fixes: 3ef193822b25 ("tpm_crb: fix fTPM on AMD Zen+ CPUs")
Reported-by: daniil.stas(a)posteo.net
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217719
Reported-by: bitlord0xff(a)gmail.com
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217212
Reviewed-by: Jason A. Donenfeld <Jason(a)zx2c4.com>
Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com>
Let me know if you need any more info.
Thanks,
Jason
The upcoming (and nearly finalized):
https://datatracker.ietf.org/doc/draft-collink-6man-pio-pflag/
will update the IPv6 RA to include a new flag in the PIO field,
which will serve as a hint to perform DHCPv6-PD.
As we don't want DHCPv6 related logic inside the kernel, this piece of
information needs to be exposed to userspace. The simplest option is to
simply expose the entire PIO through the already existing mechanism.
Even without this new flag, the already existing PIO R (router address)
flag (from RFC6275) cannot AFAICT be handled entirely in kernel,
and provides useful information that should be exposed to userspace
(the router's global address, for use by Mobile IPv6).
Also cc'ing stable@ for inclusion in LTS, as while technically this is
not quite a bugfix, and instead more of a feature, it is absolutely
trivial and the alternative is manually cherrypicking into all Android
Common Kernel trees - and I know Greg will ask for it to be sent in via
LTS instead...
Cc: Jen Linkova <furry(a)google.com>
Cc: Lorenzo Colitti <lorenzo(a)google.com>
Cc: David Ahern <dsahern(a)gmail.com>
Cc: David S. Miller <davem(a)davemloft.net>
Cc: Eric Dumazet <edumazet(a)google.com>
Cc: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji(a)linux-ipv6.org>
Cc: stable(a)vger.kernel.org
Signed-off-by: Maciej Żenczykowski <maze(a)google.com>
---
net/ipv6/ndisc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 18634ebd20a4..a42be96ae209 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -197,7 +197,8 @@ static struct nd_opt_hdr *ndisc_next_option(struct nd_opt_hdr *cur,
static inline int ndisc_is_useropt(const struct net_device *dev,
struct nd_opt_hdr *opt)
{
- return opt->nd_opt_type == ND_OPT_RDNSS ||
+ return opt->nd_opt_type == ND_OPT_PREFIX_INFO ||
+ opt->nd_opt_type == ND_OPT_RDNSS ||
opt->nd_opt_type == ND_OPT_DNSSL ||
opt->nd_opt_type == ND_OPT_CAPTIVE_PORTAL ||
opt->nd_opt_type == ND_OPT_PREF64 ||
--
2.41.0.640.ga95def55d0-goog
Every time I retest your email, it tells me to check with my ISP or
Log onto incoming mail server (POP3): Your e-mail server rejected .
Kindly verify if your email is still valid for us to talk.
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 1b8b1aa90c9c0e825b181b98b8d9e249dc395470
Gitweb: https://git.kernel.org/tip/1b8b1aa90c9c0e825b181b98b8d9e249dc395470
Author: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
AuthorDate: Thu, 03 Aug 2023 18:16:09 +03:00
Committer: Dave Hansen <dave.hansen(a)linux.intel.com>
CommitterDate: Wed, 09 Aug 2023 13:38:48 -07:00
x86/mm: Fix VDSO and VVAR placement on 5-level paging machines
Yingcong has noticed that on the 5-level paging machine, VDSO and VVAR
VMAs are placed above the 47-bit border:
8000001a9000-8000001ad000 r--p 00000000 00:00 0 [vvar]
8000001ad000-8000001af000 r-xp 00000000 00:00 0 [vdso]
This might confuse users who are not aware of 5-level paging and expect
all userspace addresses to be under the 47-bit border.
So far problem has only been triggered with ASLR disabled, although it
may also occur with ASLR enabled if the layout is randomized in a just
right way.
The problem happens due to custom placement for the VMAs in the VDSO
code: vdso_addr() tries to place them above the stack and checks the
result against TASK_SIZE_MAX, which is wrong. TASK_SIZE_MAX is set to
the 56-bit border on 5-level paging machines. Use DEFAULT_MAP_WINDOW
instead.
Fixes: b569bab78d8d ("x86/mm: Prepare to expose larger address space to userspace")
Reported-by: Yingcong Wu <yingcong.wu(a)intel.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Cc: stable(a)vger.kernel.org
Link: https://lore.kernel.org/all/20230803151609.22141-1-kirill.shutemov%40linux.…
---
arch/x86/entry/vdso/vma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 11a5c68..7645730 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -299,8 +299,8 @@ static unsigned long vdso_addr(unsigned long start, unsigned len)
/* Round the lowest possible end address up to a PMD boundary. */
end = (start + len + PMD_SIZE - 1) & PMD_MASK;
- if (end >= TASK_SIZE_MAX)
- end = TASK_SIZE_MAX;
+ if (end >= DEFAULT_MAP_WINDOW)
+ end = DEFAULT_MAP_WINDOW;
end -= len;
if (end > start) {
From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com>
Add some clarifications for patches that have dependencies within the
patch series.
Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com>
---
This patch was made after some discussions I had with Greg and Andy when
submitting a series of patches for stable inclusion:
Link: https://lkml.org/lkml/2023/8/4/21
Documentation/process/stable-kernel-rules.rst | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
index 51df1197d5ab..1c38ee009ed4 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -124,6 +124,18 @@ The tag sequence has the meaning of:
git cherry-pick fd21073
git cherry-pick <this commit>
+Note that for a patch series, you do not have to list as prerequisites the
+patches present in the series itself. For example, if you have the following
+patch series:
+
+.. code-block:: none
+
+ patch1
+ patch2
+
+where patch2 depends on patch1, you do not have to list patch1 as prerequisite
+of patch2 if you have already marked patch1 for stable inclusion.
+
Also, some patches may have kernel version prerequisites. This can be
specified in the following format in the sign-off area:
base-commit: 13b9372068660fe4f7023f43081067376582ef3c
--
2.30.2
While building Linux stable rc 6.1 x86_64 with clang-17 failed due to
following warnings / errors.
make --silent --keep-going --jobs=8
O=/home/tuxbuild/.cache/tuxmake/builds/2/build ARCH=x86_64 SRCARCH=x86
CROSS_COMPILE=x86_64-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache
clang' LLVM=1 LLVM_IAS=1
arch/x86/lib/retpoline.o: warning: objtool: .altinstr_replacement:
unexpected end of section
ld.lld: error: ./arch/x86/kernel/vmlinux.lds:191: at least one side of
the expression must be absolute
ld.lld: error: ./arch/x86/kernel/vmlinux.lds:192: at least one side of
the expression must be absolute
ld.lld: error: ./arch/x86/kernel/vmlinux.lds:191: at least one side of
the expression must be absolute
ld.lld: error: ./arch/x86/kernel/vmlinux.lds:192: at least one side of
the expression must be absolute
ld.lld: error: ./arch/x86/kernel/vmlinux.lds:191: at least one side of
the expression must be absolute
ld.lld: error: ./arch/x86/kernel/vmlinux.lds:192: at least one side of
the expression must be absolute
make[2]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 1
make[2]: Target '__default' not remade because of errors.
make[1]: *** [Makefile:1255: vmlinux] Error 2
Build links,
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2TiTUgExGs7SrTm9Lb4f…
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.4…
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.4…
Steps to reproduce:
tuxmake --runtime podman --target-arch x86_64 --toolchain clang-17
--kconfig https://storage.tuxsuite.com/public/linaro/lkft/builds/2TiTUgExGs7SrTm9Lb4f…
LLVM=1 LLVM_IAS=1
https://storage.tuxsuite.com/public/linaro/lkft/builds/2TiTUgExGs7SrTm9Lb4f…
--
Linaro LKFT
https://lkft.linaro.org
Luiz Capitulino reported the test_verifier test failed:
"precise: ST insn causing spi > allocated_stack".
And it was introduced by the following upstream commit:
ecdf985d7615 ("bpf: track immediate values written to stack by BPF_ST instruction")
Eduard's investigation [4] shows that test failure is not a bug, but a
difference in BPF verifier behavior between upstream, where commits
[1,2,3] by Andrii are present, and 5.10, where these commits are absent.
Backporting strategy is consistent with Eduard in kernel version 6.1 [5],
but with some conflicts in patch #1, #4 and #6 due to the bpf of 5.10
doesn't support more features.
Commits of Andrii:
[1] be2ef8161572 ("bpf: allow precision tracking for programs with subprogs")
[2] f63181b6ae79 ("bpf: stop setting precise in current state")
[3] 7a830b53c17b ("bpf: aggressively forget precise markings during state checkpointing")
Links:
[4] https://lore.kernel.org/stable/c9b10a8a551edafdfec855fbd35757c6238ad258.cam…
[5] https://lore.kernel.org/all/20230724124223.1176479-2-eddyz87@gmail.com/
Andrii Nakryiko (4):
bpf: allow precision tracking for programs with subprogs
bpf: stop setting precise in current state
bpf: aggressively forget precise markings during state checkpointing
selftests/bpf: make test_align selftest more robust
Ilya Leoshkevich (1):
selftests/bpf: Fix sk_assign on s390x
Yonghong Song (1):
selftests/bpf: Workaround verification failure for
fexit_bpf2bpf/func_replace_return_code
kernel/bpf/verifier.c | 175 ++++++++++++++++--
.../testing/selftests/bpf/prog_tests/align.c | 36 ++--
.../selftests/bpf/prog_tests/sk_assign.c | 25 ++-
.../selftests/bpf/progs/connect4_prog.c | 2 +-
.../selftests/bpf/progs/test_sk_assign.c | 11 ++
.../bpf/progs/test_sk_assign_libbpf.c | 3 +
6 files changed, 219 insertions(+), 33 deletions(-)
create mode 100644 tools/testing/selftests/bpf/progs/test_sk_assign_libbpf.c
--
2.25.1
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: i2c: Add a camera sensor top level menu
Author: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Date: Thu Jun 15 10:29:07 2023 +0200
Select V4L2_FWNODE and VIDEO_V4L2_SUBDEV_API for all sensor drivers. This
also adds the options to drivers that don't specifically need them, these
are still seldom used drivers using old APIs. The upside is that these
should now all compile --- many drivers have had missing dependencies.
The "menu" is replaced by selectable "menuconfig" to select the needed
V4L2_FWNODE and VIDEO_V4L2_SUBDEV_API options.
Also select MEDIA_CONTROLLER which VIDEO_V4L2_SUBDEV_API effectively
depends on, and add the I2C dependency to the menu.
Reported-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede(a)redhat.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Cc: stable(a)vger.kernel.org # for >= 6.1
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org>
drivers/media/i2c/Kconfig | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
---
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 694afb85acb9..eef5e872a824 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -25,8 +25,15 @@ config VIDEO_IR_I2C
# V4L2 I2C drivers that are related with Camera support
#
-menu "Camera sensor devices"
- visible if MEDIA_CAMERA_SUPPORT
+menuconfig VIDEO_CAMERA_SENSOR
+ bool "Camera sensor devices"
+ depends on MEDIA_CAMERA_SUPPORT && I2C
+ select MEDIA_CONTROLLER
+ select V4L2_FWNODE
+ select VIDEO_V4L2_SUBDEV_API
+ default y
+
+if VIDEO_CAMERA_SENSOR
config VIDEO_APTINA_PLL
tristate
@@ -810,7 +817,7 @@ config VIDEO_ST_VGXY61
source "drivers/media/i2c/ccs/Kconfig"
source "drivers/media/i2c/et8ek8/Kconfig"
-endmenu
+endif
menu "Lens drivers"
visible if MEDIA_CAMERA_SUPPORT