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

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

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

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

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

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 (очень распространенная) и preemption включена.

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

теперь, слово о катастрофе:

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