c - 为什么 netfilter 挂钩中的关键部分为空，会出现“BUG：原子错误时调度”？

Question

我写了这个钩子：

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/netfilter.h>
#include <linux/netfilter_ipv4.h>
#include <linux/skbuff.h>
#include <linux/mutex.h>

static struct nf_hook_ops nfho;
static struct mutex critical_section;

unsigned int hook_func(unsigned int hooknum,
   struct sk_buff **skb,
   const struct net_device *in,
   const struct net_device *out,
   int (*okfn)(struct sk_buff *)) {

  mutex_lock(&critical_section);

  mutex_unlock(&critical_section);

  return NF_ACCEPT;
}

int init_module() {

  nfho.hook = hook_func;
  nfho.hooknum = NF_INET_PRE_ROUTING;
  nfho.pf = PF_INET;
  nfho.priority = NF_IP_PRI_FIRST;

  mutex_init(&critical_section);

  nf_register_hook(&nfho);

  return 0;
}

void cleanup_module() {
  nf_unregister_hook(&nfho);
}

初始化部分：

  mutex_init(&queue_critical_section);
  mutex_init(&ioctl_critical_section);

我已经定义了静态变量：

static struct mutex queue_critical_section;

由于之间没有代码lock，unlock我希望没有错误，但是当我运行这个模块时，内核会产生这些错误：

错误更新：

root@khajavi: # pppd call 80-2
[  519.722190] PPP generic driver version 2.4.2
root@khajavi:# [  519.917390] BUG: scheduling while atomic: swapper/0/0/0x10000100
[  519.940933] Modules linked in: ppp_async crc_ccitt ppp_generic slhc netfilter_mutex(P) nls_utf8 isofs udf crc_itu_t bnep    rfcomm bluetooth rfkill vboxsf(O) vboxvideo(O) drm]
[  520.022203] CPU 0 
[  520.023270] Modules linked in: ppp_async crc_ccitt ppp_generic slhc netfilter_mutex(P) nls_utf8 isofs udf crc_itu_t bnep rfcomm bluetooth rfkill vboxsf(O) vboxvideo(O) drm]
[  520.087002] 
[  520.088001] Pid: 0, comm: swapper/0 Tainted: P           O 3.2.51 #3 innotek GmbH VirtualBox/VirtualBox
[  520.130047] RIP: 0010:[<ffffffff8102d17d>]  [<ffffffff8102d17d>] native_safe_halt+0x6/0x8
[  520.135010] RSP: 0018:ffffffff81601ee8  EFLAGS: 00000246
[  520.140999] RAX: 0000000000000000 RBX: ffffffff810a4cfa RCX: ffffffffffffffbe
[  520.145972] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000001
[  520.158759] RBP: ffffffff81601ee8 R08: 0000000000000000 R09: 0000000000000000
[  520.163392] R10: 0000000000000400 R11: ffff88003fc13680 R12: 0000000000014040
[  520.172784] R13: ffff88003fc14040 R14: ffffffff81067fd2 R15: ffffffff81601e58
[  520.177767] FS:  0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[  520.188208] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  520.196486] CR2: 00007fff961a3f40 CR3: 0000000001605000 CR4: 00000000000006f0
[  520.201437] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  520.212332] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  520.217155] Process swapper/0 (pid: 0, threadinfo ffffffff81600000, task ffffffff8160d020)
[  520.228706] Stack:
[  520.234394]  ffffffff81601ef8
Message from syslogd@khajavi at Dec 22 17:45:46 ...
 kernel:[  520.228706] Stack:
 ffffffff81014857 ffffffff81601f28 ffffffff8100d2a3
[  520.255069]  ffffffffffffffff 0d64eb669fae50fc ffffffff81601f28 0000000000000000
[  520.269238]  ffffffff81601f38 ffffffff81358c39 ffffffff81601f78 ffffffff816acb8a
[  520.274148] Call Trace:
[  520.275573]  [<ffffffff81014857>] default_idle+0x49/0x81
[  520.278985]  [<ffffffff8100d2a3>] cpu_idle+0xbc/0xcf
[  520.291491]  [<ffffffff81358c39>] rest_init+0x6d/0x6f

这是完整的系统日志错误： http: //paste.ubuntu.com/6617614/

score 8 · Accepted Answer

这是内核内部的一个钩子。不允许休眠、锁定信号量（挂起）或任何阻塞操作；您正在锁定内核！

如果你想要同步对象，你可以尝试使用自旋锁。

正如对类似问题的回答所述，mutex_lock 将触发调度程序；但是内核会感到困惑，因为您正试图安排另一个任务，而您正处于临界区（回调本身就是大临界区）。

检查此线程了解类似情况的 netfilter 钩子的执行上下文。

score 6 · Accepted Answer

Even though mutex_lock() probably won't sleep in this case, it still might sleep. Since this is called in an atomic context, the error is raised.

Specifically, this is caused by mutex_lock() calling might_sleep(), which in turn may call __schedule()

If you do need to synchronize, use the appropriate calls, eg. spinlocks and rcu.

score 5 · Accepted Answer

如果您的任务在保持同步（很可能是自旋锁）时调度，您会看到此消息。当您锁定自旋锁时，它会增加 preempt_count；当调度程序厌恶增加 preempt_count 的调度情况时，它会打印出确切的消息：

/* * 在原子错误时打印调度：

 */
static noinline void __schedule_bug(struct task_struct *prev)
{
        if (oops_in_progress)
                return;

        printk(KERN_ERR "BUG: scheduling while atomic: %s/%d/0x%08x\n",
                prev->comm, prev->pid, preempt_count());

        debug_show_held_locks(prev);
        print_modules();
        if (irqs_disabled())
                print_irqtrace_events(prev);
        dump_stack();
}

所以，可能你拿着一把锁，或者你必须解锁一些锁。

PS。从 Linux 文档中的互斥锁描述：

'struct mutex' 语义是明确定义的，并且在 CONFIG_DEBUG_MUTEXES 开启时强制执行。另一方面，信号量
几乎没有调试代码或仪器。互斥体子系统
检查并执行以下规则：

一次只有一个任务可以持有互斥锁 * - 只有所有者可以解锁互斥锁 * - 不允许多次解锁

不允许递归锁定 * - 必须通过 API 初始化互斥对象 * - 不得通过 memset 或复制来初始化互斥对象 * - 任务可能不会在持有互斥的情况下退出 * - 不能释放持有的锁所在的内存区域* - 持有的互斥锁不得重新初始化 * - 互斥锁不得用于硬件或软件中断 * 上下文，例如小任务和计时器

在您的设计中，可以同时多次使用相同的互斥锁：

调用 1 -> 你的代码 -> mutex_lock
调度程序会中断您的代码。
调用 2 -> 您的代码 -> mutex_lock（已锁定）-> BUG

祝你好运。

score 4 · Accepted Answer

这显然是一个执行上下文问题。要在内核代码中使用适当的锁定，需要知道代码在哪个执行上下文 ( hard_irq| bottom_half| process_context) 中被调用。

mutex_lock| mutex_unlock 仅用于保护 process_context 代码。

根据http://www.gossamer-threads.com/lists/iptables/devel/56853

讨论，你的函数hook_func可以在sot_irqor中调用process_context。因此，您需要使用适合在这两个上下文之间进行保护的锁定机制。

我建议您阅读内核锁定指南（https://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/）。该指南还解释了当系统为 SMP（非常常见）并且启用抢占时所涉及的特性。

为了快速测试，您可以spin_lock_irqsave在hook_func. spin_lock_irqsave始终是安全的，它禁用当前 cpu 上的中断，并且自旋锁将保证 SMP 系统上的原子操作。

现在，关于崩溃的消息：

mutex_lock| mutex_unlock只能在 process_context 代码中使用。当您hook_func从调用时soft_irq，mutex_lock会导致当前进程进入睡眠状态，进而调用调度程序。在原子上下文中不允许在内核代码中休眠（这里是soft_irq）。

c - 为什么 netfilter 挂钩中的关键部分为空，会出现“BUG：原子错误时调度”？

错误更新：

4 回答 4

Related

Reference