- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 0/1] kvm: arm64: Add HIP13 cpu type definition for detecting virtualization features
by liqiqi 08 May '26

08 May '26

Add HIP13 cpu type for detecting whether IPIv and DVMBM are supported. liqiqi (1): kvm: arm64: Add HIP13 cpu type definition for detecting virtualization features arch/arm64/kvm/hisilicon/hisi_virt.c | 12 +++++++----- arch/arm64/kvm/hisilicon/hisi_virt.h | 1 + 2 files changed, 8 insertions(+), 5 deletions(-) -- 2.43.0

2 2

[PATCH OLK-5.10] bpf: Fix regsafe() for pointers to packet
by Pu Lehui 08 May '26

08 May '26

From: Alexei Starovoitov <ast(a)kernel.org> mainline inclusion from mainline-v7.0-rc7 commit a8502a79e832b861e99218cbd2d8f4312d62e225 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8900 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In case rold->reg->range == BEYOND_PKT_END && rcur->reg->range == N regsafe() may return true which may lead to current state with valid packet range not being explored. Fix the bug. Fixes: 6d94e741a8ff ("bpf: Support for pointers beyond pkt_end.") Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Reviewed-by: Daniel Borkmann <daniel(a)iogearbox.net> Reviewed-by: Amery Hung <ameryhung(a)gmail.com> Acked-by: Eduard Zingerman <eddyz87(a)gmail.com> Link: https://lore.kernel.org/bpf/20260331204228.26726-1-alexei.starovoitov@gmail… Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/verifier.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 13df8a2fc4d7..678a98e86398 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -9706,8 +9706,13 @@ static bool regsafe(struct bpf_verifier_env *env, struct bpf_reg_state *rold, * since someone could have accessed through (ptr - k), or * even done ptr -= k in a register, to get a safe access. */ - if (rold->range > rcur->range) + if (rold->range < 0 || rcur->range < 0) { + /* special case for [BEYOND|AT]_PKT_END */ + if (rold->range != rcur->range) + return false; + } else if (rold->range > rcur->range) { return false; + } /* If the offsets don't match, we can't trust our alignment; * nor can we be sure that we won't fall out of range. */ -- 2.34.1

2 1

[PATCH OLK-6.6] mm/userfaultfd: fix hugetlb fault mutex hash calculation
by Ze Zuo 08 May '26

08 May '26

From: Jianhui Zhou <jianhuizzzzz(a)gmail.com> mainline inclusion from mainline-v7.1-rc1 commit 0217c7fb4de4a40cee667eb21901f3204effe5ac category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14321 CVE: CVE-2026-31575 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In mfill_atomic_hugetlb(), linear_page_index() is used to calculate the page index for hugetlb_fault_mutex_hash(). However, linear_page_index() returns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash() expects the index in huge page units. This mismatch means that different addresses within the same huge page can produce different hash values, leading to the use of different mutexes for the same huge page. This can cause races between faulting threads, which can corrupt the reservation map and trigger the BUG_ON in resv_map_release(). Fix this by introducing hugetlb_linear_page_index(), which returns the page index in huge page granularity, and using it in place of linear_page_index(). Link: https://lkml.kernel.org/r/20260310110526.335749-1-jianhuizzzzz@gmail.com Fixes: a08c7193e4f1 ("mm/filemap: remove hugetlb special casing in filemap.c") Signed-off-by: Jianhui Zhou <jianhuizzzzz(a)gmail.com> Reported-by: syzbot+f525fd79634858f478e7(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f525fd79634858f478e7 Acked-by: SeongJae Park <sj(a)kernel.org> Reviewed-by: David Hildenbrand (Arm) <david(a)kernel.org> Acked-by: Mike Rapoport (Microsoft) <rppt(a)kernel.org> Cc: Jane Chu <jane.chu(a)oracle.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: JonasZhou <JonasZhou(a)zhaoxin.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Peter Xu <peterx(a)redhat.com> Cc: SeongJae Park <sj(a)kernel.org> Cc: Sidhartha Kumar <sidhartha.kumar(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: include/linux/hugetlb.h [Conflict due not to meger commit 4a25f995bd59("mm: hugetlb: directly pass order when allocate a hugetlb folio"), context conflict.] Signed-off-by: Ze Zuo <zuoze1(a)huawei.com> --- include/linux/hugetlb.h | 17 +++++++++++++++++ mm/userfaultfd.c | 2 +- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index e4e243bad311..419f72303370 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -896,6 +896,23 @@ static inline unsigned huge_page_shift(struct hstate *h) return h->order + PAGE_SHIFT; } +/** + * hugetlb_linear_page_index() - linear_page_index() but in hugetlb + * page size granularity. + * @vma: the hugetlb VMA + * @address: the virtual address within the VMA + * + * Return: the page offset within the mapping in huge page units. + */ +static inline pgoff_t hugetlb_linear_page_index(struct vm_area_struct *vma, + unsigned long address) +{ + struct hstate *h = hstate_vma(vma); + + return ((address - vma->vm_start) >> huge_page_shift(h)) + + (vma->vm_pgoff >> huge_page_order(h)); +} + static inline bool hstate_is_gigantic(struct hstate *h) { return huge_page_order(h) > MAX_ORDER; diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c index 2c71a269a52c..53afe2e97bc1 100644 --- a/mm/userfaultfd.c +++ b/mm/userfaultfd.c @@ -468,7 +468,7 @@ static __always_inline ssize_t mfill_atomic_hugetlb( * in the case of shared pmds. fault mutex prevents * races with other faulting threads. */ - idx = linear_page_index(dst_vma, dst_addr); + idx = hugetlb_linear_page_index(dst_vma, dst_addr); mapping = dst_vma->vm_file->f_mapping; hash = hugetlb_fault_mutex_hash(mapping, idx); mutex_lock(&hugetlb_fault_mutex_table[hash]); -- 2.25.1

2 1

[PATCH OLK-6.6] EDAC/mc: Fix error path ordering in edac_mc_alloc()
by Ye Bin 07 May '26

07 May '26

From: "Borislav Petkov (AMD)" <bp(a)alien8.de> stable inclusion from stable-v6.6.135 commit d3de72e2a2b9ee3a57734c1c068823e41a707715 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14436 CVE: CVE-2026-31689 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 51520e03e70d6c73e33ee7cbe0319767d05764fe upstream. When the mci->pvt_info allocation in edac_mc_alloc() fails, the error path will call put_device() which will end up calling the device's release function. However, the init ordering is wrong such that device_initialize() happens *after* the failed allocation and thus the device itself and the release function pointer are not initialized yet when they're called: MCE: In-kernel MCE decoding enabled. ------------[ cut here ]------------ kobject: '(null)': is not initialized, yet kobject_put() is being called. WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full) RIP: 0010:kobject_put Call Trace: <TASK> edac_mc_alloc+0xbe/0xe0 [edac_core] amd64_edac_init+0x7a4/0xff0 [amd64_edac] ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac] do_one_initcall ... Reorder the calling sequence so that the device is initialized and thus the release function pointer is properly set before it can be used. This was found by Claude while reviewing another EDAC patch. Fixes: 0bbb265f7089 ("EDAC/mc: Get rid of silly one-shot struct allocation in edac_mc_alloc()") Reported-by: Claude Code:claude-opus-4.5 Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com> Cc: stable(a)kernel.org Link: https://patch.msgid.link/20260331121623.4871-1-bp@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- drivers/edac/edac_mc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c index 6faeb2ab3960..952ebd94e0ec 100644 --- a/drivers/edac/edac_mc.c +++ b/drivers/edac/edac_mc.c @@ -369,13 +369,13 @@ struct mem_ctl_info *edac_mc_alloc(unsigned int mc_num, if (!mci->layers) goto error; + mci->dev.release = mci_release; + device_initialize(&mci->dev); + mci->pvt_info = kzalloc(sz_pvt, GFP_KERNEL); if (!mci->pvt_info) goto error; - mci->dev.release = mci_release; - device_initialize(&mci->dev); - /* setup index and various internal pointers */ mci->mc_idx = mc_num; mci->tot_dimms = tot_dimms; -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] net: Fix CVE-2026-31518
by Dong Chenchen 07 May '26

07 May '26

Fix CVE-2026-31518 Sabrina Dubroca (1): esp: fix skb leak with espintcp and async crypto Steffen Klassert (1): xfrm: Fix the usage of skb->sk net/ipv4/esp4.c | 11 +++++++---- net/ipv6/esp6.c | 11 +++++++---- net/ipv6/xfrm6_output.c | 4 ++-- net/xfrm/xfrm_interface_core.c | 2 +- net/xfrm/xfrm_output.c | 7 ++++--- net/xfrm/xfrm_policy.c | 2 +- 6 files changed, 22 insertions(+), 15 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6 0/2] net/sched: Fix CVE-2026-31421
by Dong Chenchen 07 May '26

07 May '26

Fix CVE-2026-31421 Davide Caratti (1): net/sched: cls_fw: fix NULL dereference of "old" filters before change() Xiang Mei (1): net/sched: cls_fw: fix NULL pointer dereference on shared blocks net/sched/cls_fw.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) -- 2.25.1

2 3

[PATCH OLK-5.10] x86/CPU: Fix FPDSS on Zen1
by Zhang Kunbo 07 May '26

07 May '26

From: "Borislav Petkov (AMD)" <bp(a)alien8.de> stable inclusion from stable-v5.10.253 commit ed7a3a246309ccc807238f1b4f159ee6d37ff9c4 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14370 CVE: CVE-2026-31628 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e55d98e7756135f32150b9b8f75d580d0d4b2dd3 upstream. Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit. Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: arch/x86/kernel/cpu/amd.c [ context conflict] Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/x86/include/asm/msr-index.h | 3 +++ arch/x86/kernel/cpu/amd.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h index a01922b0ed82..01175f84c89d 100644 --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -521,6 +521,9 @@ #define MSR_AMD64_DC_CFG 0xc0011022 #define MSR_AMD64_TW_CFG 0xc0011023 +#define MSR_AMD64_FP_CFG 0xc0011028 +#define MSR_AMD64_FP_CFG_ZEN1_DENORM_FIX_BIT 9 + #define MSR_AMD64_DE_CFG 0xc0011029 #define MSR_AMD64_DE_CFG_LFENCE_SERIALIZE_BIT 1 #define MSR_AMD64_DE_CFG_LFENCE_SERIALIZE BIT_ULL(MSR_AMD64_DE_CFG_LFENCE_SERIALIZE_BIT) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index cb66f17855dd..b9944748634e 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1041,6 +1041,9 @@ static void init_amd_zen1(struct cpuinfo_x86 *c) msr_clear_bit(MSR_K7_HWCR, MSR_K7_HWCR_IRPERF_EN_BIT); clear_cpu_cap(c, X86_FEATURE_IRPERF); } + + pr_notice_once("AMD Zen1 FPDSS bug detected, enabling mitigation.\n"); + msr_set_bit(MSR_AMD64_FP_CFG, MSR_AMD64_FP_CFG_ZEN1_DENORM_FIX_BIT); } static bool cpu_has_zenbleed_microcode(void) -- 2.34.1

2 1

[PATCH OLK-6.6] usb: cdns3: gadget: fix state inconsistency on gadget init failure
by Xinyu Zheng 07 May '26

07 May '26

From: Yongchao Wu <yongchao.wu(a)autochips.com> stable inclusion from stable-v6.6.134 commit cfca84f5986afceb63a3adf39d4a98e915aebbc2 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14504 CVE: CVE-2026-31754 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit c32f8748d70c8fc77676ad92ed76cede17bf2c48 upstream. When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode while software state remains INACTIVE, creating hardware/software state inconsistency. When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/role The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error, so cdns_role_stop() skips cleanup because state is still INACTIVE. This violates the DRD controller design specification (Figure22), which requires returning to idle state before switching roles. This leads to a synchronous external abort in xhci_gen_setup() when setting up the host controller: [ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19 [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed ... [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 1301.382485] pc : xhci_gen_setup+0xa4/0x408 [ 1301.393391] backtrace: ... xhci_gen_setup+0xa4/0x408 <-- CRASH xhci_plat_setup+0x44/0x58 usb_add_hcd+0x284/0x678 ... cdns_role_set+0x9c/0xbc <-- Role switch Fix by calling cdns_drd_gadget_off() in the error path to properly clean up the DRD gadget state. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable <stable(a)kernel.org> Signed-off-by: Yongchao Wu <yongchao.wu(a)autochips.com> Acked-by: Peter Chen <peter.chen(a)kernel.org> Link: https://patch.msgid.link/20260401001000.5761-1-yongchao.wu@autochips.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Xinyu Zheng <zhengxinyu6(a)huawei.com> --- drivers/usb/cdns3/cdns3-gadget.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/cdns3/cdns3-gadget.c b/drivers/usb/cdns3/cdns3-gadget.c index 05e8414c31df..344de9c202cd 100644 --- a/drivers/usb/cdns3/cdns3-gadget.c +++ b/drivers/usb/cdns3/cdns3-gadget.c @@ -3428,6 +3428,7 @@ static int __cdns3_gadget_init(struct cdns *cdns) ret = cdns3_gadget_start(cdns); if (ret) { pm_runtime_put_sync(cdns->dev); + cdns_drd_gadget_off(cdns); return ret; } -- 2.34.1

2 1

[PATCH OLK-5.10] futex: Clear stale exiting pointer in futex_lock_pi() retry path
by Jiacheng Yu 07 May '26

07 May '26

From: Davidlohr Bueso <dave(a)stgolabs.net> stable inclusion from stable-v5.10.253 commit 33095ae3bdde5e5c264d7e88a2f3e7703a26c7aa category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14301 CVE: CVE-2026-31555 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 210d36d892de5195e6766c45519dfb1e65f3eb83 upstream. Fuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524 When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'. After wait_for_owner_exiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a different error, the bogus pointer is passed to wait_for_owner_exiting(). CPU0 CPU1 CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; futex_lock_pi(uaddr) futex_lock_pi_atomic() attach_to_pi_owner() // observes EXITING *exiting = owner; // takes ref return -EBUSY wait_for_owner_exiting(-EBUSY, owner) put_task_struct(); // drops ref // exiting still points to owner goto retry; futex_lock_pi_atomic() lock_pi_update_atomic() cmpxchg(uaddr) *uaddr ^= WAITERS // whatever // value changed return -EAGAIN; wait_for_owner_exiting(-EAGAIN, exiting) // stale WARN_ON_ONCE(exiting) Fix this by resetting upon retry, essentially aligning it with requeue_pi. Fixes: 3ef240eaff36 ("futex: Prevent exit livelock") Signed-off-by: Davidlohr Bueso <dave(a)stgolabs.net> Signed-off-by: Thomas Gleixner <tglx(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20260326001759.4129680-1-dave@stgolabs.net Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jiacheng Yu <yujiacheng3(a)huawei.com> --- kernel/futex/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/futex/core.c b/kernel/futex/core.c index cde0ca876b935..df86c0e494184 100644 --- a/kernel/futex/core.c +++ b/kernel/futex/core.c @@ -2785,9 +2785,9 @@ static int futex_lock_pi(u32 __user *uaddr, unsigned int flags, ktime_t *time, int trylock) { struct hrtimer_sleeper timeout, *to; - struct task_struct *exiting = NULL; struct rt_mutex_waiter rt_waiter; struct futex_hash_bucket *hb; + struct task_struct *exiting; struct futex_q q = futex_q_init; int res, ret; @@ -2800,6 +2800,7 @@ static int futex_lock_pi(u32 __user *uaddr, unsigned int flags, to = futex_setup_timer(time, &timeout, FLAGS_CLOCKRT, 0); retry: + exiting = NULL; ret = get_futex_key(uaddr, flags & FLAGS_SHARED, &q.key, FUTEX_WRITE); if (unlikely(ret != 0)) goto out; -- 2.43.0

2 1

[PATCH OLK-6.6] futex: Clear stale exiting pointer in futex_lock_pi() retry path
by Jiacheng Yu 07 May '26

07 May '26

From: Davidlohr Bueso <dave(a)stgolabs.net> stable inclusion from stable-v6.6.131 commit de7c0c04ad868f2cee6671b11c0a6d20421af1da category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14301 CVE: CVE-2026-31555 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 210d36d892de5195e6766c45519dfb1e65f3eb83 upstream. Fuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524 When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'. After wait_for_owner_exiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a different error, the bogus pointer is passed to wait_for_owner_exiting(). CPU0 CPU1 CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; futex_lock_pi(uaddr) futex_lock_pi_atomic() attach_to_pi_owner() // observes EXITING *exiting = owner; // takes ref return -EBUSY wait_for_owner_exiting(-EBUSY, owner) put_task_struct(); // drops ref // exiting still points to owner goto retry; futex_lock_pi_atomic() lock_pi_update_atomic() cmpxchg(uaddr) *uaddr ^= WAITERS // whatever // value changed return -EAGAIN; wait_for_owner_exiting(-EAGAIN, exiting) // stale WARN_ON_ONCE(exiting) Fix this by resetting upon retry, essentially aligning it with requeue_pi. Fixes: 3ef240eaff36 ("futex: Prevent exit livelock") Signed-off-by: Davidlohr Bueso <dave(a)stgolabs.net> Signed-off-by: Thomas Gleixner <tglx(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20260326001759.4129680-1-dave@stgolabs.net Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jiacheng Yu <yujiacheng3(a)huawei.com> --- kernel/futex/pi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/futex/pi.c b/kernel/futex/pi.c index ce2889f123755..9496084b6dcd8 100644 --- a/kernel/futex/pi.c +++ b/kernel/futex/pi.c @@ -930,9 +930,9 @@ int fixup_pi_owner(u32 __user *uaddr, struct futex_q *q, int locked) int futex_lock_pi(u32 __user *uaddr, unsigned int flags, ktime_t *time, int trylock) { struct hrtimer_sleeper timeout, *to; - struct task_struct *exiting = NULL; struct rt_mutex_waiter rt_waiter; struct futex_hash_bucket *hb; + struct task_struct *exiting; struct futex_q q = futex_q_init; int res, ret; @@ -945,6 +945,7 @@ int futex_lock_pi(u32 __user *uaddr, unsigned int flags, ktime_t *time, int tryl to = futex_setup_timer(time, &timeout, flags, 0); retry: + exiting = NULL; ret = get_futex_key(uaddr, flags & FLAGS_SHARED, &q.key, FUTEX_WRITE); if (unlikely(ret != 0)) goto out; -- 2.43.0

2 1