gpt4 book ai didi

在进程上下文中调用 kmap_atomic()

转载 作者:行者123 更新时间:2023-11-30 15:00:12 24 4
gpt4 key购买 nike

我有一个内核模块。它有一个 IOCTL,用于分配页面,然后使用 kmap_atomic 一次一页映射到内核。

当我通过测试应用程序运行此 ioctl 练习时,我收到以下调度 BUG:

    [41216.007065] BUG: scheduling while atomic: app/1242/0x00000002
[41216.007403] Modules linked in: allocator(O) gpu(O) [last unloaded: gpu]
[41216.007910] CPU: 0 PID: 1242 Comm: app Tainted: G W O 4.10.0-rc5-00111-g49e555a-dirty #22
[41216.008385] Hardware name: linux,dummy-virt (DT)
[41216.008667] Call trace:
[41216.008907] [<ffff000008088ba0>] dump_backtrace+0x0/0x23c
[41216.009242] [<ffff000008088df0>] show_stack+0x14/0x1c
[41216.009563] [<ffff000008375efc>] dump_stack+0x94/0xb4
[41216.010318] [<ffff00000816bcb0>] __schedule_bug+0x58/0x6c
[41216.010723] [<ffff0000088a9204>] __schedule+0x404/0x574
[41216.011099] [<ffff0000088a93ac>] schedule+0x38/0x9c
[41216.011454] [<ffff00000808873c>] do_notify_resume+0x90/0xa0
[41216.011844] [<ffff000008083618>] work_pending+0x8/0x10

有谁知道这是什么原因造成的吗?在内核中,此消息打印在 kernel/sched/core.c 中因为以下检查是正确的

    if (unlikely(in_atomic_preempt_off())) {
__schedule_bug(prev);
preempt_count_set(PREEMPT_DISABLED);
}

此检查在 include/linux/preempt.h 中定义

    /*
* Check whether we were atomic before we did preempt_disable():
* (used by the scheduler)
*/
#define in_atomic_preempt_off() (preempt_count() != PREEMPT_DISABLE_OFFSET)

如果这对任何人都有意义,请分享您的观点。

最佳答案

kmap_atomic()kunmap_atomic之间<​​strong>不允许休眠。

来自Documentation/vm/highmem.txt :

kmap_atomic(). This permits a very short duration mapping of a single page. Since the mapping is restricted to the CPU that issued it, it performs well, but the issuing task is therefore required to stay on that CPU until it has finished, lest some other task displace its mappings.

关于在进程上下文中调用 kmap_atomic(),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42266641/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com