MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/2206
JIRA: https://issues.redhat.com/browse/RHEL-134674
See the commit description for the problem description and how it's resolved by this change. The description is still valid after the changes made in the commit for RHEL as described below.
The commit changes are still valid because to identify the mount namespace of the automount owner (the process that manages the automounting for the given mount) an id is used. The id the upstream patch uses is a new id (in a commit also merged at the time this patch was posted) contained in struct ns_common which contains namespace common fields. Prior to these patches there is another id located in struct mnt_namespace that's part of a union which is valid while the namespace itself is valid and is used instead of the new id as was suggested by the upstream patch series author, also the VFS maintainer.
Signed-off-by: Ian Kent <ikent@redhat.com>
Approved-by: Pavel Reichl <preichl@redhat.com>
Approved-by: Andreas Gruenbacher <agruenba@redhat.com>
Approved-by: Abhi Das <adas@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: Alexandra Hájková <ahajkova@redhat.com>
JIRA: INTERNAL
Upstream Status: RHEL only
Support also new JIRA cloud server hostname. We will eventually remove
the old one.
Signed-off-by: Jan Stancek <jstancek@redhat.com>
JIRA: INTERNAL
Upstream Status: RHEL only
commit b20bb303e13511d863821beafff4a2210e2c0009
Author: Jan Stancek <jstancek@redhat.com>
Date: Mon Mar 2 03:59:55 2026 -0500
redhat/scripts: remove remnants of git notes usage and dead code
We stopped using git notes in downstream RHELs for changelog metadata
a while ago, so these can be dropped along with some other dead code.
Signed-off-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Jan Stancek <jstancek@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-152916
commit fb321998de7639f1954430674475e469fb529d9c
Author: NeilBrown <neil@brown.name>
Date: Mon Dec 15 08:07:28 2025 +1100
nfsd: use correct loop termination in nfsd4_revoke_states()
The loop in nfsd4_revoke_states() stops one too early because
the end value given is CLIENT_HASH_MASK where it should be
CLIENT_HASH_SIZE.
This means that an admin request to drop all locks for a filesystem will
miss locks held by clients which hash to the maximum possible hash value.
Fixes: 1ac3629bf0 ("nfsd: prepare for supporting admin-revocation of state")
Cc: stable@vger.kernel.org
Signed-off-by: NeilBrown <neil@brown.name>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Olga Kornievskaia <okorniev@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-152916
commit d0424066fcd294977f310964bed6f2a487fa4515
Author: Olga Kornievskaia <okorniev@redhat.com>
Date: Mon Dec 15 14:10:36 2025 -0500
nfsd: check that server is running in unlock_filesystem
If we are trying to unlock the filesystem via an administrative
interface and nfsd isn't running, it crashes the server. This
happens currently because nfsd4_revoke_states() access state
structures (eg., conf_id_hashtbl) that has been freed as a part
of the server shutdown.
[ 59.465072] Call trace:
[ 59.465308] nfsd4_revoke_states+0x1b4/0x898 [nfsd] (P)
[ 59.465830] write_unlock_fs+0x258/0x440 [nfsd]
[ 59.466278] nfsctl_transaction_write+0xb0/0x120 [nfsd]
[ 59.466780] vfs_write+0x1f0/0x938
[ 59.467088] ksys_write+0xfc/0x1f8
[ 59.467395] __arm64_sys_write+0x74/0xb8
[ 59.467746] invoke_syscall.constprop.0+0xdc/0x1e8
[ 59.468177] do_el0_svc+0x154/0x1d8
[ 59.468489] el0_svc+0x40/0xe0
[ 59.468767] el0t_64_sync_handler+0xa0/0xe8
[ 59.469138] el0t_64_sync+0x1ac/0x1b0
Ensure this can't happen by taking the nfsd_mutex and checking that
the server is still up, and then holding the mutex across the call to
nfsd4_revoke_states().
Reviewed-by: NeilBrown <neil@brown.name>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Fixes: 1ac3629bf0 ("nfsd: prepare for supporting admin-revocation of state")
Cc: stable@vger.kernel.org
Signed-off-by: Olga Kornievskaia <okorniev@redhat.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Olga Kornievskaia <okorniev@redhat.com>
MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-10/-/merge_requests/787
JIRA: https://issues.redhat.com/browse/RHEL-151754
Upstream Status: net.git
Upstream we agreed on making `child_ns_mode` write-once. So this is the backport of https://lore.kernel.org/netdev/20260223-vsock-ns-write-once-v3-0-c0cde6959923@meta.com/ just landed on `net` tree. From that series:
Two administrator processes may race when setting child_ns_mode: one
sets it to "local" and creates a namespace, but another changes it to
"global" in between. The first process ends up with a namespace in the
wrong mode. Make child_ns_mode write-once so that a namespace manager
can set it once, check the value, and be guaranteed it won't change
before creating its namespaces. Writing a different value after the
first write returns -EBUSY.
The last 2 patches are from that series, the other 2 are needed to make the backport clean:
```
$ git backport-diff -u upstream/net -r HEAD~4..HEAD 2>/dev/null
Key:
[----] : patches are identical
[####] : number of functional differences between upstream/downstream patch
[down] : patch is downstream-only
The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively
001/4:[----] [--] 'vsock: document namespace mode sysctls'
002/4:[----] [--] 'vsock: Use container_of() to get net namespace in sysctl handlers'
003/4:[----] [--] 'vsock: lock down child_ns_mode as write-once'
004/4:[----] [--] 'vsock: document write-once behavior of the child_ns_mode sysctl'
```
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Closes RHEL-151754
Approved-by: Davide Caratti <dcaratti@redhat.com>
Approved-by: Luigi Leonardi <leonardi@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-10/-/merge_requests/779
JIRA: https://issues.redhat.com/browse/RHEL-146369
Note that preliminary ARK config mismatch is reasonable for now because CONFIG_DPLL_REFCNT_TRACKER will be part of kernel v7.0 that was not merged to kernel-ark yet.
Commits:
```
d0f4771e2bef ("dpll: Allow associating dpll pin with a firmware node")
e6dc7727b608 ("dpll: zl3073x: Associate pin with fwnode handle")
2be467588d6b ("dpll: Add notifier chain for dpll events")
711696b3e168 ("dpll: Support dynamic pin index allocation")
fdad05ed4ec2 ("dpll: zl3073x: Add support for mux pin type")
729f5e0153bd ("dpll: Enhance and consolidate reference counting logic")
3c0da1030c58 ("dpll: Add reference count tracking support")
085ca5d20171 ("drivers: Add support for DPLL reference count tracking")
ad1df4f2d591 ("ice: dpll: Support E825-C SyncE and dynamic pin discovery")
```
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Approved-by: Petr Oros <poros@redhat.com>
Approved-by: José Ignacio Tornos Martínez <jtornosm@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
JIRA: https://issues.redhat.com/browse/RHEL-138728
commit fb2ff9fa72e20a75cab0ffc9dc8735de68ed4d0d
Author: Srikar Dronamraju <srikar@linux.ibm.com>
Date: Wed Nov 12 13:18:59 2025 +0530
powerpc/smp: Expose die_id and die_cpumask
>From Power10 processors onwards, each chip has 2 hemispheres. For LPARs
running on PowerVM Hypervisor, hypervisor determines the allocation of
CPU groups to each LPAR, resulting in two LPARs with the same number of
CPUs potentially having different numbers of CPUs from each hemisphere.
Additionally, it is not feasible to ascertain the hemisphere based
solely on the CPU number.
Users wishing to assign their workload to all CPUs, or a subset of CPUs
within a specific hemisphere, encounter difficulties in identifying the
cpumask. To address this, it is proposed to expose hemisphere
information as a die in sysfs. This aligns with other architectures
and facilitates the identification of CPUs within the same hemisphere.
Tools such as lstopo can also access this information.
Please note: The hypervisor reveals the locality of the CPUs to
hemispheres only in dedicated mode. Consequently, in systems where
hemisphere information is unavailable, such as shared LPARs, the
die_cpus information in sysfs will mirror package_cpus, with
die_id set to -1.
Without this change.
$ grep . /sys/devices/system/cpu/cpu16/topology/{die*,package*} 2>/dev/null
/sys/devices/system/cpu/cpu16/topology/package_cpus:000000,000000ff,ffff0000
/sys/devices/system/cpu/cpu16/topology/package_cpus_list:16-39
With this change.
$ grep . /sys/devices/system/cpu/cpu16/topology/{die*,package*} 2>/dev/null
/sys/devices/system/cpu/cpu16/topology/die_cpus:000000,00000000,00ff0000
/sys/devices/system/cpu/cpu16/topology/die_cpus_list:16-23
/sys/devices/system/cpu/cpu16/topology/die_id:2
/sys/devices/system/cpu/cpu16/topology/package_cpus:000000,000000ff,ffff0000
/sys/devices/system/cpu/cpu16/topology/package_cpus_list:16-39
snipped lstopo-no-graphics o/p
Group0 L#0 (total=8747584KB)
Package L#0 (total=3564096KB CPUModel="POWER10 (architected), altivec supported" CPURevision="2.0 (pvr 0080 0200)")
NUMANode L#0 (P#0 local=3564096KB total=3564096KB)
Die L#0 (P#0)
Core L#0 (P#0)
<snipped>
Package L#1 (total=5183488KB CPUModel="POWER10 (architected), altivec supported" CPURevision="2.0 (pvr 0080 0200)")
NUMANode L#1 (P#1 local=5183488KB total=5183488KB)
Die L#2 (P#2)
Core L#2 (P#16)
L3Cache L#4 (size=4096KB linesize=128 ways=16)
L2Cache L#4 (size=1024KB linesize=128 ways=8)
L1dCache L#4 (size=32KB linesize=128 ways=8)
L1iCache L#4 (size=48KB linesize=128 ways=6)
PU L#16 (P#16)
PU L#17 (P#18)
PU L#18 (P#20)
PU L#19 (P#22)
L3Cache L#5 (size=4096KB linesize=128 ways=16)
L2Cache L#5 (size=1024KB linesize=128 ways=8)
L1dCache L#5 (size=32KB linesize=128 ways=8)
L1iCache L#5 (size=48KB linesize=128 ways=6)
PU L#20 (P#17)
PU L#21 (P#19)
PU L#22 (P#21)
PU L#23 (P#23)
Die L#3 (P#3)
Core L#3 (P#24)
L3Cache L#6 (size=4096KB linesize=128 ways=16)
L2Cache L#6 (size=1024KB linesize=128 ways=8)
L1dCache L#6 (size=32KB linesize=128 ways=8)
L1iCache L#6 (size=48KB linesize=128 ways=6)
PU L#24 (P#24)
PU L#25 (P#26)
PU L#26 (P#28)
PU L#27 (P#30)
L3Cache L#7 (size=4096KB linesize=128 ways=16)
L2Cache L#7 (size=1024KB linesize=128 ways=8)
L1dCache L#7 (size=32KB linesize=128 ways=8)
L1iCache L#7 (size=48KB linesize=128 ways=6)
PU L#28 (P#25)
PU L#29 (P#27)
PU L#30 (P#29)
PU L#31 (P#31)
Core L#4 (P#32)
L3Cache L#8 (size=4096KB linesize=128 ways=16)
L2Cache L#8 (size=1024KB linesize=128 ways=8)
L1dCache L#8 (size=32KB linesize=128 ways=8)
L1iCache L#8 (size=48KB linesize=128 ways=6)
PU L#32 (P#32)
PU L#33 (P#34)
PU L#34 (P#36)
PU L#35 (P#38)
L3Cache L#9 (size=4096KB linesize=128 ways=16)
L2Cache L#9 (size=1024KB linesize=128 ways=8)
L1dCache L#9 (size=32KB linesize=128 ways=8)
L1iCache L#9 (size=48KB linesize=128 ways=6)
PU L#36 (P#33)
PU L#37 (P#35)
PU L#38 (P#37)
PU L#39 (P#39)
Group0 L#1 (total=7736896KB)
Package L#2 (total=5170880KB CPUModel="POWER10 (architected), altivec supported" CPURevision="2.0 (pvr 0080 0200)")
NUMANode L#2 (P#2 local=5170880KB total=5170880KB)
Die L#4 (P#4)
<snipped>
Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Signed-off-by: Srikar Dronamraju <srikar@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20251112074859.814087-1-srikar@linux.ibm.com
Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-134674
Upstream status: Linus
Conflicts: The upstream patch uses an id added to struct ns_common in
upstream commit 885fc8ac0a4dc ("nstree: make iterator generic") but
this commit has only recently been merged upstream. However the seq
field of struct mnt_namespace (which contains struct ns_common) can
be used to identify the mount namespace so that's what's used instead.
commit 922a6f34c1756d2b0c35d9b2d915b8af19e85965
Author: Ian Kent <raven@themaw.net>
Date: Tue Nov 18 10:46:31 2025 +0800
autofs: dont trigger mount if it cant succeed
If a mount namespace contains autofs mounts, and they are propagation
private, and there is no namespace specific automount daemon to handle
possible automounting then attempted path resolution will loop until
MAXSYMLINKS is reached before failing causing quite a bit of noise in
the log.
Add a check for this in autofs ->d_automount() so that the VFS can
immediately return an error in this case. Since the mount is propagation
private an EPERM return seems most appropriate.
Suggested by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Ian Kent <raven@themaw.net>
Link: https://patch.msgid.link/20251118024631.10854-2-raven@themaw.net
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Ian Kent <ikent@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-148618
commit 3611ca7c12b740e250d83f8bbe3554b740c503b0
Author: Sean Christopherson <seanjc@google.com>
Date: Mon Dec 29 12:23:30 2025 -0800
selftests: kvm: Verify TILELOADD actually #NM faults when XFD[18]=1
Rework the AMX test's #NM handling to use kvm_asm_safe() to verify an #NM
actually occurs. As is, a completely missing #NM could go unnoticed.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-148618
commit 0383a8edef396cf0a6884b0be81d62bde60737b0
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Wed Dec 31 16:47:26 2025 +0100
selftests: kvm: try getting XFD and XSAVE state out of sync
The host is allowed to set FPU state that includes a disabled
xstate component. Check that this does not cause bad effects.
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-148618
commit a1025dcd377ef92d9a09af03b70ce80be281ee22
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Wed Dec 24 00:44:49 2025 +0100
selftests: kvm: replace numbered sync points with actions
Rework the guest=>host syncs in the AMX test to use named actions instead
of arbitrary, incrementing numbers. The "stage" of the test has no real
meaning, what matters is what action the test wants the host to perform.
The incrementing numbers are somewhat helpful for triaging failures, but
fully debugging failures almost always requires a much deeper dive into
the test (and KVM).
Using named actions not only makes it easier to extend the test without
having to shift all sync point numbers, it makes the code easier to read.
[Commit message by Sean Christopherson]
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-148618
commit b45f721775947a84996deb5c661602254ce25ce6
Author: Sean Christopherson <seanjc@google.com>
Date: Wed Dec 31 16:43:15 2025 +0100
x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1
When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in
response to a guest WRMSR, clear XFD-disabled features in the saved (or to
be restored) XSTATE_BV to ensure KVM doesn't attempt to load state for
features that are disabled via the guest's XFD. Because the kernel
executes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1
will cause XRSTOR to #NM and panic the kernel.
E.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV:
------------[ cut here ]------------
WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848
Modules linked in: kvm_intel kvm irqbypass
CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:exc_device_not_available+0x101/0x110
Call Trace:
<TASK>
asm_exc_device_not_available+0x1a/0x20
RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90
switch_fpu_return+0x4a/0xb0
kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm]
kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]
__x64_sys_ioctl+0x8f/0xd0
do_syscall_64+0x62/0x940
entry_SYSCALL_64_after_hwframe+0x4b/0x53
</TASK>
---[ end trace 0000000000000000 ]---
This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1,
and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler's
call to fpu_update_guest_xfd().
and if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE:
------------[ cut here ]------------
WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867
Modules linked in: kvm_intel kvm irqbypass
CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:exc_device_not_available+0x101/0x110
Call Trace:
<TASK>
asm_exc_device_not_available+0x1a/0x20
RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90
fpu_swap_kvm_fpstate+0x6b/0x120
kvm_load_guest_fpu+0x30/0x80 [kvm]
kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm]
kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]
__x64_sys_ioctl+0x8f/0xd0
do_syscall_64+0x62/0x940
entry_SYSCALL_64_after_hwframe+0x4b/0x53
</TASK>
---[ end trace 0000000000000000 ]---
The new behavior is consistent with the AMX architecture. Per Intel's SDM,
XSAVE saves XSTATE_BV as '0' for components that are disabled via XFD
(and non-compacted XSAVE saves the initial configuration of the state
component):
If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i,
the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1;
instead, it operates as if XINUSE[i] = 0 (and the state component was
in its initial state): it saves bit i of XSTATE_BV field of the XSAVE
header as 0; in addition, XSAVE saves the initial configuration of the
state component (the other instructions do not save state component i).
Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using
a constant XFD based on the set of enabled features when XSAVEing for
a struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled
features can only happen in the above interrupt case, or in similar
scenarios involving preemption on preemptible kernels, because
fpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves the
outgoing FPU state with the current XFD; and that is (on all but the
first WRMSR to XFD) the guest XFD.
Therefore, XFD can only go out of sync with XSTATE_BV in the above
interrupt case, or in similar scenarios involving preemption on
preemptible kernels, and it we can consider it (de facto) part of KVM
ABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.
Reported-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: stable@vger.kernel.org
Fixes: 820a6ee944 ("kvm: x86: Add emulation for IA32_XFD", 2022-01-14)
Signed-off-by: Sean Christopherson <seanjc@google.com>
[Move clearing of XSTATE_BV from fpu_copy_uabi_to_guest_fpstate
to kvm_vcpu_ioctl_x86_set_xsave. - Paolo]
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-148618
commit fddd07626baa419c259ad5f3537a57188b5bb415
Author: Sean Christopherson <seanjc@google.com>
Date: Fri Sep 19 15:32:50 2025 -0700
KVM: x86: Define AMD's #HV, #VC, and #SX exception vectors
Add {HV,CP,SX}_VECTOR definitions for AMD's Hypervisor Injection Exception,
VMM Communication Exception, and SVM Security Exception vectors, along with
human friendly formatting for trace_kvm_inj_exception().
Note, KVM is all but guaranteed to never observe or inject #SX, and #HV is
also unlikely to go unused. Add the architectural collateral mostly for
completeness, and on the off chance that hardware goes off the rails.
Link: https://lore.kernel.org/r/20250919223258.1604852-44-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-148618
commit 7b39b6c76942d42d3eecf0844d0f6a76fb64e805
Author: Sean Christopherson <seanjc@google.com>
Date: Tue Sep 9 13:28:32 2025 -0700
KVM: selftests: Add support for #DE exception fixup
Add support for handling #DE (divide error) exceptions in KVM selftests
so that the fastops test can verify KVM correctly handles #DE when
emulating DIV or IDIV on behalf of the guest. Morph #DE to 0xff (i.e.
to -1) as a mostly-arbitrary vector to indicate #DE, so that '0' (the
real #DE vector) can still be used to indicate "no exception".
Link: https://lore.kernel.org/r/20250909202835.333554-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-152643
Upstream-status: RHEL-only
The NXP S32G3 family uses the compatible "nxp,s32g2-ocotp" for its
On-Chip One-Time Programming (OCOTP) controller, which requires
NVMEM_S32G_OCOTP. Enable this in automotive as a module.
Signed-off-by: Jared Kangas <jkangas@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-151838
commit d9d1e319b39ea685ede59319002d567c159d23c3
Author: Paulo Alcantara <pc@manguebit.org>
Date: Wed Feb 25 21:34:55 2026 -0300
smb: client: fix broken multichannel with krb5+signing
When mounting a share with 'multichannel,max_channels=n,sec=krb5i',
the client was duplicating signing key for all secondary channels,
thus making the server fail all commands sent from secondary channels
due to bad signatures.
Every channel has its own signing key, so when establishing a new
channel with krb5 auth, make sure to use the new session key as the
derived key to generate channel's signing key in SMB2_auth_kerberos().
Repro:
$ mount.cifs //srv/share /mnt -o multichannel,max_channels=4,sec=krb5i
$ sleep 5
$ umount /mnt
$ dmesg
...
CIFS: VFS: sign fail cmd 0x5 message id 0x2
CIFS: VFS: \\srv SMB signature verification returned error = -13
CIFS: VFS: sign fail cmd 0x5 message id 0x2
CIFS: VFS: \\srv SMB signature verification returned error = -13
CIFS: VFS: sign fail cmd 0x4 message id 0x2
CIFS: VFS: \\srv SMB signature verification returned error = -13
Reported-by: Xiaoli Feng <xifeng@redhat.com>
Reviewed-by: Enzo Matsumiya <ematsumiya@suse.de>
Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
Cc: David Howells <dhowells@redhat.com>
Cc: linux-cifs@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Paulo Alcantara <paalcant@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-151838
Upstream-Status: RHEL-only
Due to a bad backport of upstream commit 62432a3f5145 ("cifs: Clean up
some places where an extra kvec[] was required for rfc1002") in RHEL
10.2, one call to cifs_shash_iter() on request's data iterator was
missed, therefore breaking signing of read and write requests.
This is a serious bug, especially when doing buffered IO as the
requests will fail over the wire due to bad signatures while having
read(2) & write(2) calls to succeed.
Signed-off-by: Paulo Alcantara <paalcant@redhat.com>
Alexandra Hájková
Scott Weaver
Jan Stancek
CKI KWF Bot
Roberto Bergantinos Corpas
Olga Kornievskaia
Mamatha Inamdar
Ian Kent
Maxim Levitsky
Jared Kangas
Paulo Alcantara