Ответ 1

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

  • • только одна задача может удерживать мьютекс за раз * - только владелец может разблокировать мьютекс * - множественные разблокировки не разрешены
  • • рекурсивная блокировка не разрешена * - объект mutex должен быть инициализирован через API * - объект mutex не должен быть инициализирован через memset или копирование * - задача не может выйти с сохраненным мьютексом * - области памяти, в которых хранятся удерживаемые замки, не должны быть освобождены * - проведены мьютексы не должны быть повторно инициализированы * - мьютексы не могут использоваться в аппаратные или программные прерывания * контексты, такие как задачи и таймеры

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

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

Удачи.

Ответ 4

Это явно проблема контекста выполнения. Чтобы использовать соответствующую блокировку в коде ядра, необходимо знать, в каком контексте выполнения (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 всегда безопасен, он отключает прерывания на текущем процессоре, а spinlock гарантирует работу атома в SMP-системе.

Теперь, слово о сбое:

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