Это хук изнутри ядра. Спящий режим, блокировка семафора (ожидание) или любые блокирующие операции не допускаются; Вы блокируете ядро!

Если вам нужен объект синхронизации, вы можете попробовать использовать спин-блокировки.

Как указано в этом ответе на аналогичный вопрос, mutex_lock вызовет планировщик; Но ядро ​​будет озадачено, потому что вы пытаетесь запланировать другую задачу, в то время как вы находитесь в критической секции (сам обратный вызов является большой критической секцией).

Проверьте эту тему Понимание контекста выполнения перехватчиков netfilter для аналогичного случая.

Несмотря на то, что mutex_lock() в этом случае, скорее всего, не заснет, он все же может заснуть. Поскольку это вызывается в атомарном контексте, возникает ошибка.

В частности, это вызвано тем, что mutex_lock() вызывает might_sleep(), который, в свою очередь, может вызывать __schedule()

Если вам нужна синхронизация, используйте соответствующие вызовы, например. спинлоки и rcu.

Вы видите это сообщение, если ваша задача запланирована, когда она содержит синхронизацию, скорее всего, спин-блокировку. Когда вы блокируете спин-блокировку, она увеличивает 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 включен. С другой стороны, семафоры
  практически не имеют ни кода отладки, ни инструментария. Подсистема мьютекса
  проверяет и применяет следующие правила:

  • • only one task can hold the mutex at a time * - only the owner can unlock the mutex * - multiple unlocks are not permitted
  • • recursive locking is not permitted * - a mutex object must be initialized via the API * - a mutex object must not be initialized via memset or copying * - task may not exit with mutex held * - memory areas where held locks reside must not be freed * - held mutexes must not be reinitialized * - mutexes may not be used in hardware or software interrupt * contexts such as tasklets and timers

В вашем дизайне один и тот же мьютекс может использоваться несколько раз одновременно:

1. вызов 1 -> ваш код -> mutex_lock
2. планировщик прерывает ваш код.
3. вызов 2 -> ваш код -> mutex_lock (уже заблокирован) -> ОШИБКА

Удачи.

Это явно проблема контекста выполнения. Чтобы использовать соответствующую блокировку в коде ядра, нужно знать, в каком контексте выполнения (hard_irq | bottom_half | process_context) вызывается код.

mutex_lock | mutex_unlock предназначены исключительно для защиты кода process_context.

согласно http://www.gossamer-threads.com/lists/iptables/devel/56853

обсуждение, ваша функция hook_func может быть вызвана в sot_irq или process_context. Итак, вам нужно использовать механизм блокировки, подходящий для защиты между этими двумя контекстами.

Я предлагаю вам ознакомиться с руководством по блокировке ядра (https://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/). В руководстве также объясняются особенности, возникающие, когда система находится в режиме SMP (очень распространено) и включено вытеснение.

для быстрой проверки вы можете использовать блокировку spin_lock_irqsave в своем hook_func. spin_lock_irqsave всегда безопасен, он отключает прерывания на текущем процессоре, а спин-блокировка гарантирует атомарную работу в системе SMP.

Теперь немного о крушении:

mutex_lock | mutex_unlock можно использовать только в коде process_context. Когда ваш hook_func вызывается из soft_irq, mutex_lock переводит текущий процесс в спящий режим и, в свою очередь, вызывает планировщик. Засыпание в коде ядра не разрешено в атомарном контексте (здесь это soft_irq).