mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2025 -----
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

  • 65 participants
  • 18442 discussions
[PATCH OLK-6.6 V1] sched: Fix bpf cpustats refcount leak
by Cheng Yu 06 Jan '25

06 Jan '25
From: Hui Tang <tanghui20(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBG1V2 CVE: NA -------------------------------- Refcount 'cpustats->usage' is clear in bpf_sched_cpu_stats_of which triggering WARNING bpf_sched_cpustats_release called. refcount_t: underflow; use-after-free. WARNING: CPU: 31 PID: 9517 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148 Call trace: refcount_warn_saturate+0xf4/0x148 bpf_sched_cpustats_release+0xa4/0xc0 bpf_prog_62f48e1f0ef32ae3_select_rq+0x360/0x398 bpf_trampoline_6442463850+0x8c/0x1000 bpf_sched_cfs_select_rq+0x8/0x18 select_task_rq_fair+0x250/0x4c8 Ctx is clear in bpf_sched_cpustats_create, so it not need to clear in bpf_sched_cpu_stats_of. Fixes: ace175278fa1 ("sched: Add kfunc to get cpu statistics") Signed-off-by: Hui Tang <tanghui20(a)huawei.com> Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- kernel/sched/bpf_sched.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/sched/bpf_sched.c b/kernel/sched/bpf_sched.c index 2958b3029d38..1973cfacc079 100644 --- a/kernel/sched/bpf_sched.c +++ b/kernel/sched/bpf_sched.c @@ -152,7 +152,6 @@ __bpf_kfunc s32 bpf_sched_cpu_stats_of(int cpuid, return -EINVAL; rq = cpu_rq(cpu); - memset(ctx, 0, sizeof(*ctx)); SCHED_WARN_ON(!rcu_read_lock_held()); /* nr_running */ -- 2.25.1
2 1
0 0
[PATCH OLK-6.6] KVM: arm64: Don't retire aborted MMIO instruction
by Zhang Kunbo 06 Jan '25

06 Jan '25
From: Oliver Upton <oliver.upton(a)linux.dev> stable inclusion from stable-v6.6.66 commit ea6b5d98fea4ee8cb443ea98fda520909e90d30e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAG3 CVE: CVE-2024-53196 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e735a5da64420a86be370b216c269b5dd8e830e2 ] Returning an abort to the guest for an unsupported MMIO access is a documented feature of the KVM UAPI. Nevertheless, it's clear that this plumbing has seen limited testing, since userspace can trivially cause a WARN in the MMIO return: WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 Call trace: kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133 kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487 __do_sys_ioctl fs/ioctl.c:51 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 The splat is complaining that KVM is advancing PC while an exception is pending, i.e. that KVM is retiring the MMIO instruction despite a pending synchronous external abort. Womp womp. Fix the glaring UAPI bug by skipping over all the MMIO emulation in case there is a pending synchronous exception. Note that while userspace is capable of pending an asynchronous exception (SError, IRQ, or FIQ), it is still safe to retire the MMIO instruction in this case as (1) they are by definition asynchronous, and (2) KVM relies on hardware support for pending/delivering these exceptions instead of the software state machine for advancing PC. Cc: stable(a)vger.kernel.org Fixes: da345174ceca ("KVM: arm/arm64: Allow user injection of external data aborts") Reported-by: Alexander Potapenko <glider(a)google.com> Reviewed-by: Marc Zyngier <maz(a)kernel.org> Link: https://lore.kernel.org/r/20241025203106.3529261-2-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: arch/arm64/kvm/mmio.c [ different return polarity introduced by this commit not merged: cc81b6dfc3bc8 ("KVM: arm64: Change kvm_handle_mmio_return() return polarity") ] Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/arm64/kvm/mmio.c | 32 ++++++++++++++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kvm/mmio.c b/arch/arm64/kvm/mmio.c index 40d6d056e261..bf5de05cb7a8 100644 --- a/arch/arm64/kvm/mmio.c +++ b/arch/arm64/kvm/mmio.c @@ -73,6 +73,31 @@ unsigned long kvm_mmio_read_buf(const void *buf, unsigned int len) return data; } +static bool kvm_pending_sync_exception(struct kvm_vcpu *vcpu) +{ + if (!vcpu_get_flag(vcpu, PENDING_EXCEPTION)) + return false; + + if (vcpu_el1_is_32bit(vcpu)) { + switch (vcpu_get_flag(vcpu, EXCEPT_MASK)) { + case unpack_vcpu_flag(EXCEPT_AA32_UND): + case unpack_vcpu_flag(EXCEPT_AA32_IABT): + case unpack_vcpu_flag(EXCEPT_AA32_DABT): + return true; + default: + return false; + } + } else { + switch (vcpu_get_flag(vcpu, EXCEPT_MASK)) { + case unpack_vcpu_flag(EXCEPT_AA64_EL1_SYNC): + case unpack_vcpu_flag(EXCEPT_AA64_EL2_SYNC): + return true; + default: + return false; + } + } +} + /** * kvm_handle_mmio_return -- Handle MMIO loads after user space emulation * or in-kernel IO emulation @@ -85,8 +110,11 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu) unsigned int len; int mask; - /* Detect an already handled MMIO return */ - if (unlikely(!vcpu->mmio_needed)) + /* + * Detect if the MMIO return was already handled or if userspace aborted + * the MMIO access. + */ + if (unlikely(!vcpu->mmio_needed || kvm_pending_sync_exception(vcpu))) return 0; vcpu->mmio_needed = 0; -- 2.34.1
2 1
0 0
[PATCH OLK-6.6] f2fs: fix to account dirty data in __get_secs_required()
by Liu Mingrui 06 Jan '25

06 Jan '25
From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v6.6.64 commit f1b8bfe8d2f2fdf905d37c174d5bc1cd2b6910c5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBA6RL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1acd73edbbfef2c3c5b43cba4006a7797eca7050 ] It will trigger system panic w/ testcase in [1]: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2752! RIP: 0010:new_curseg+0xc81/0x2110 Call Trace: f2fs_allocate_data_block+0x1c91/0x4540 do_write_page+0x163/0xdf0 f2fs_outplace_write_data+0x1aa/0x340 f2fs_do_write_data_page+0x797/0x2280 f2fs_write_single_data_page+0x16cd/0x2190 f2fs_write_cache_pages+0x994/0x1c80 f2fs_write_data_pages+0x9cc/0xea0 do_writepages+0x194/0x7a0 filemap_fdatawrite_wbc+0x12b/0x1a0 __filemap_fdatawrite_range+0xbb/0xf0 file_write_and_wait_range+0xa1/0x110 f2fs_do_sync_file+0x26f/0x1c50 f2fs_sync_file+0x12b/0x1d0 vfs_fsync_range+0xfa/0x230 do_fsync+0x3d/0x80 __x64_sys_fsync+0x37/0x50 x64_sys_call+0x1e88/0x20d0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is if checkpoint_disabling and lfs_mode are both on, it will trigger OPU for all overwritten data, it may cost more free segment than expected, so f2fs must account those data correctly to calculate cosumed free segments later, and return ENOSPC earlier to avoid run out of free segment during block allocation. [1] https://lore.kernel.org/fstests/20241015025106.3203676-1-chao@kernel.org/ Fixes: 4354994f097d ("f2fs: checkpoint disabling") Cc: Daniel Rosenberg <drosen(a)google.com> Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> Signed-off-by: Liu Mingrui <liumingrui(a)huawei.com> --- fs/f2fs/segment.h | 35 +++++++++++++++++++++++++---------- 1 file changed, 25 insertions(+), 10 deletions(-) diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index 952970166d5d..cd2ec6acc717 100644 --- a/fs/f2fs/segment.h +++ b/fs/f2fs/segment.h @@ -559,18 +559,21 @@ static inline int reserved_sections(struct f2fs_sb_info *sbi) } static inline bool has_curseg_enough_space(struct f2fs_sb_info *sbi, - unsigned int node_blocks, unsigned int dent_blocks) + unsigned int node_blocks, unsigned int data_blocks, + unsigned int dent_blocks) { - unsigned segno, left_blocks; + unsigned int segno, left_blocks, blocks; int i; - /* check current node sections in the worst case. */ - for (i = CURSEG_HOT_NODE; i <= CURSEG_COLD_NODE; i++) { + /* check current data/node sections in the worst case. */ + for (i = CURSEG_HOT_DATA; i < NR_PERSISTENT_LOG; i++) { segno = CURSEG_I(sbi, i)->segno; left_blocks = CAP_BLKS_PER_SEC(sbi) - get_ckpt_valid_blocks(sbi, segno, true); - if (node_blocks > left_blocks) + + blocks = i <= CURSEG_COLD_DATA ? data_blocks : node_blocks; + if (blocks > left_blocks) return false; } @@ -584,8 +587,9 @@ static inline bool has_curseg_enough_space(struct f2fs_sb_info *sbi, } /* - * calculate needed sections for dirty node/dentry - * and call has_curseg_enough_space + * calculate needed sections for dirty node/dentry and call + * has_curseg_enough_space, please note that, it needs to account + * dirty data as well in lfs mode when checkpoint is disabled. */ static inline void __get_secs_required(struct f2fs_sb_info *sbi, unsigned int *lower_p, unsigned int *upper_p, bool *curseg_p) @@ -594,19 +598,30 @@ static inline void __get_secs_required(struct f2fs_sb_info *sbi, get_pages(sbi, F2FS_DIRTY_DENTS) + get_pages(sbi, F2FS_DIRTY_IMETA); unsigned int total_dent_blocks = get_pages(sbi, F2FS_DIRTY_DENTS); + unsigned int total_data_blocks = 0; unsigned int node_secs = total_node_blocks / CAP_BLKS_PER_SEC(sbi); unsigned int dent_secs = total_dent_blocks / CAP_BLKS_PER_SEC(sbi); + unsigned int data_secs = 0; unsigned int node_blocks = total_node_blocks % CAP_BLKS_PER_SEC(sbi); unsigned int dent_blocks = total_dent_blocks % CAP_BLKS_PER_SEC(sbi); + unsigned int data_blocks = 0; + + if (f2fs_lfs_mode(sbi) && + unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED))) { + total_data_blocks = get_pages(sbi, F2FS_DIRTY_DATA); + data_secs = total_data_blocks / CAP_BLKS_PER_SEC(sbi); + data_blocks = total_data_blocks % CAP_BLKS_PER_SEC(sbi); + } if (lower_p) - *lower_p = node_secs + dent_secs; + *lower_p = node_secs + dent_secs + data_secs; if (upper_p) *upper_p = node_secs + dent_secs + - (node_blocks ? 1 : 0) + (dent_blocks ? 1 : 0); + (node_blocks ? 1 : 0) + (dent_blocks ? 1 : 0) + + (data_blocks ? 1 : 0); if (curseg_p) *curseg_p = has_curseg_enough_space(sbi, - node_blocks, dent_blocks); + node_blocks, data_blocks, dent_blocks); } static inline bool has_not_enough_free_secs(struct f2fs_sb_info *sbi, -- 2.25.1
2 1
0 0
[PATCH openEuler-22.03-LTS-SP1] gpiolib: fix memory use-after-free in gpiochip_setup_dev()
by He Yujie 06 Jan '25

06 Jan '25
hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB8UN5 CVE: CVE-2022-48975 -------------------------------- Commit aa1e2bfdc899 attempt to fix a CVE problem, but the patch conflicted with current version. When the patch is adapted, an error is introduced in the function of gpiochip_add_data_with_key. After the gdev is released, the gdev is still accessed, resulting in use-after-free. The value of gdev->ngpio is assigned from gc->ngpio and is not changed during the processing of function. Therefore, this patch changes gdev->ngpio to gc->ngpio to solve the above use-after-free problem. Fixes: aa1e2bfdc899 ("gpiolib: fix memory leak in gpiochip_setup_dev()") Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- drivers/gpio/gpiolib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 206d73810876..07d26ca22c2c 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -796,7 +796,7 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data, err_print_message: /* failures here can mean systems won't boot... */ pr_err("%s: GPIOs %d..%d (%s) failed to register, %d\n", __func__, - base, base + gdev->ngpio - 1, + base, base + (int)gc->ngpio - 1, gc->label ? : "generic", ret); return ret; } -- 2.34.1
2 1
0 0
[PATCH openEuler-1.0-LTS 0/1] etmem: fix use-after-free of mm in the scan release process
by chenrenhui 06 Jan '25

06 Jan '25
etmem: fix use-after-free of mm in the scan release process chenrenhui (1): etmem: fix use-after-free of mm in the scan release process fs/proc/task_mmu.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.33.0
2 2
0 0
[PATCH OLK-6.6 0/1] etmem: fix use-after-free of mm in the scan release process
by chenrenhui 06 Jan '25

06 Jan '25
etmem: fix use-after-free of mm in the scan release process chenrenhui (1): etmem: fix use-after-free of mm in the scan release process fs/proc/etmem_proc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.33.0
2 2
0 0
[PATCH openEuler-25.03 0/1] etmem: fix use-after-free of mm in the scan release process
by chenrenhui 06 Jan '25

06 Jan '25
etmem: fix use-after-free of mm in the scan release process chenrenhui (1): etmem: fix use-after-free of mm in the scan release process fs/proc/etmem_proc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.33.0
1 1
0 0
[PATCH openEuler-22.03-LTS-SP1 0/1] etmem: fix use-after-free of mm in the scan release process
by chenrenhui 06 Jan '25

06 Jan '25
etmem: fix use-after-free of mm in the scan release process chenrenhui (1): etmem: fix use-after-free of mm in the scan release process fs/proc/task_mmu.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.33.0
2 2
0 0
[PATCH openEuler-25.03 0/1] etmem: fix use-after-free of mm in the scan release process
by chenrenhui 06 Jan '25

06 Jan '25
etmem: fix use-after-free of mm in the scan release process chenrenhui (1): etmem: fix use-after-free of mm in the scan release process fs/proc/etmem_proc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.33.0
1 1
0 0
[PATCH OLK-6.6] Bluetooth: MGMT: Fix possible deadlocks
by dinglongwei 06 Jan '25

06 Jan '25
From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> stable inclusion from stable-v6.6.64 commit 5703fb1d85f653e35b327b14de4db7da239e4fd9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAGI CVE: CVE-2024-53207 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a66dfaf18fd61bb75ef8cee83db46b2aadf153d0 ] This fixes possible deadlocks like the following caused by hci_cmd_sync_dequeue causing the destroy function to run: INFO: task kworker/u19:0:143 blocked for more than 120 seconds. Tainted: G W O 6.8.0-2024-03-19-intel-next-iLS-24ww14 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u19:0 state:D stack:0 pid:143 tgid:143 ppid:2 flags:0x00004000 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: <TASK> __schedule+0x374/0xaf0 schedule+0x3c/0xf0 schedule_preempt_disabled+0x1c/0x30 __mutex_lock.constprop.0+0x3ef/0x7a0 __mutex_lock_slowpath+0x13/0x20 mutex_lock+0x3c/0x50 mgmt_set_connectable_complete+0xa4/0x150 [bluetooth] ? kfree+0x211/0x2a0 hci_cmd_sync_dequeue+0xae/0x130 [bluetooth] ? __pfx_cmd_complete_rsp+0x10/0x10 [bluetooth] cmd_complete_rsp+0x26/0x80 [bluetooth] mgmt_pending_foreach+0x4d/0x70 [bluetooth] __mgmt_power_off+0x8d/0x180 [bluetooth] ? _raw_spin_unlock_irq+0x23/0x40 hci_dev_close_sync+0x445/0x5b0 [bluetooth] hci_set_powered_sync+0x149/0x250 [bluetooth] set_powered_sync+0x24/0x60 [bluetooth] hci_cmd_sync_work+0x90/0x150 [bluetooth] process_one_work+0x13e/0x300 worker_thread+0x2f7/0x420 ? __pfx_worker_thread+0x10/0x10 kthread+0x107/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3d/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Tested-by: Kiran K <kiran.k(a)intel.com> Fixes: f53e1c9c726d ("Bluetooth: MGMT: Fix possible crash on mgmt_index_removed") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- net/bluetooth/mgmt.c | 27 ++++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c index 1f3a39c20a91..2238f431858a 100644 --- a/net/bluetooth/mgmt.c +++ b/net/bluetooth/mgmt.c @@ -1503,7 +1503,8 @@ static void mgmt_set_discoverable_complete(struct hci_dev *hdev, void *data, bt_dev_dbg(hdev, "err %d", err); /* Make sure cmd still outstanding. */ - if (cmd != pending_find(MGMT_OP_SET_DISCOVERABLE, hdev)) + if (err == -ECANCELED || + cmd != pending_find(MGMT_OP_SET_DISCOVERABLE, hdev)) return; hci_dev_lock(hdev); @@ -1677,7 +1678,8 @@ static void mgmt_set_connectable_complete(struct hci_dev *hdev, void *data, bt_dev_dbg(hdev, "err %d", err); /* Make sure cmd still outstanding. */ - if (cmd != pending_find(MGMT_OP_SET_CONNECTABLE, hdev)) + if (err == -ECANCELED || + cmd != pending_find(MGMT_OP_SET_CONNECTABLE, hdev)) return; hci_dev_lock(hdev); @@ -1910,7 +1912,7 @@ static void set_ssp_complete(struct hci_dev *hdev, void *data, int err) bool changed; /* Make sure cmd still outstanding. */ - if (cmd != pending_find(MGMT_OP_SET_SSP, hdev)) + if (err == -ECANCELED || cmd != pending_find(MGMT_OP_SET_SSP, hdev)) return; if (err) { @@ -3775,7 +3777,8 @@ static void set_name_complete(struct hci_dev *hdev, void *data, int err) bt_dev_dbg(hdev, "err %d", err); - if (cmd != pending_find(MGMT_OP_SET_LOCAL_NAME, hdev)) + if (err == -ECANCELED || + cmd != pending_find(MGMT_OP_SET_LOCAL_NAME, hdev)) return; if (status) { @@ -3950,7 +3953,8 @@ static void set_default_phy_complete(struct hci_dev *hdev, void *data, int err) struct sk_buff *skb = cmd->skb; u8 status = mgmt_status(err); - if (cmd != pending_find(MGMT_OP_SET_PHY_CONFIGURATION, hdev)) + if (err == -ECANCELED || + cmd != pending_find(MGMT_OP_SET_PHY_CONFIGURATION, hdev)) return; if (!status) { @@ -5841,13 +5845,16 @@ static void start_discovery_complete(struct hci_dev *hdev, void *data, int err) { struct mgmt_pending_cmd *cmd = data; + bt_dev_dbg(hdev, "err %d", err); + + if (err == -ECANCELED) + return; + if (cmd != pending_find(MGMT_OP_START_DISCOVERY, hdev) && cmd != pending_find(MGMT_OP_START_LIMITED_DISCOVERY, hdev) && cmd != pending_find(MGMT_OP_START_SERVICE_DISCOVERY, hdev)) return; - bt_dev_dbg(hdev, "err %d", err); - mgmt_cmd_complete(cmd->sk, cmd->index, cmd->opcode, mgmt_status(err), cmd->param, 1); mgmt_pending_remove(cmd); @@ -6080,7 +6087,8 @@ static void stop_discovery_complete(struct hci_dev *hdev, void *data, int err) { struct mgmt_pending_cmd *cmd = data; - if (cmd != pending_find(MGMT_OP_STOP_DISCOVERY, hdev)) + if (err == -ECANCELED || + cmd != pending_find(MGMT_OP_STOP_DISCOVERY, hdev)) return; bt_dev_dbg(hdev, "err %d", err); @@ -8025,7 +8033,8 @@ static void read_local_oob_ext_data_complete(struct hci_dev *hdev, void *data, u8 status = mgmt_status(err); u16 eir_len; - if (cmd != pending_find(MGMT_OP_READ_LOCAL_OOB_EXT_DATA, hdev)) + if (err == -ECANCELED || + cmd != pending_find(MGMT_OP_READ_LOCAL_OOB_EXT_DATA, hdev)) return; if (!status) { -- 2.22.0
2 1
0 0
  • ← Newer
  • 1
  • ...
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • ...
  • 1845
  • Older →

HyperKitty Powered by HyperKitty