11

私はこのフックを書きました：

#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

ここに完全な syslog エラーがあります: http://paste.ubuntu.com/6617614/

4

4 に答える 4

5

このメッセージは、タスクが同期 (おそらくスピンロック) を保持しているときにスケジュールされている場合に表示されます。スピンロックをロックすると、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 がオンになっている場合に適用されます。一方、セマフォには
    実質的にデバッグ コードやインストルメンテーションがありません。ミューテックス サブシステム
    は、次のルールをチェックして適用します。

      • 一度に 1 つのタスクのみがミューテックスを保持できます * - 所有者のみがミューテックスをロック解除できます * - 複数のロック解除は許可されていません
      • 再帰ロックは許可されていません * - API を介してミューテックス オブジェクトを初期化する必要があります * - memset またはコピーを介してミューテックス オブジェクトを初期化してはなりません * - ミューテックスを保持したままタスクを終了できません * - 保持されたロックが存在するメモリ領域を解放してはなりません* - 保持されたミューテックスは再初期化してはなりません * - ミューテックスはハードウェアまたはソフトウェア割り込みで使用できません * タスクレットやタイマーなどのコンテキスト

あなたの設計では、同じミューテックスが同時に複数回使用される可能性があります。

  1. 1 を呼び出します -> あなたのコード -> mutex_lock
  2. スケジューラーがコードを中断します。
  3. 2 を呼び出します -> コード -> mutex_lock (既にロックされています) -> BUG

幸運を。

于 2013-12-26T16:16:57.503 に答える