Каковы возможные причины «BUG: планирование в то время как атомарный?»

Существует другой процесс, постоянно создающий файлы, которые требуют обработки этим кодом.
Этот код постоянно сканирует файловую систему на наличие новых файлов, требующих обработки, сравнивая содержимое файловой системы с базой данных sqlite, содержащей результаты обработки — по одной записи для каждого файла. Этот процесс выполняется в nice -n 19 чтобы не мешать созданию новых файлов другим процессом.
Все это прекрасно работает для большого количества (> 1k) файлов, но затем взрывается BUG: scheduling while atomic,
В соответствии с этот

«Планирование в атомном режиме» означает, что вы пытались заснуть
где-то, что вы не должны

Но единственный сон в коде такой

void doFiles(void) {
for (...) { // for each file in the file-system
... // check database - do processing if needed
}
sleep(1);
}
int main(int argc, char *argv[], char *envp[]) {
while (true) doFiles();
return -1;
}

Код перейдет в режим ожидания после того, как проверит каждый файл в файловой системе по базе данных. Процесс необходимо повторить, так как новые файлы будут добавляться время от времени. В этом коде нет многопоточности. Существуют ли другие возможные причины для «БУГ: планирование в то время как атомарное» помимо неуместного сна?

Редактировать: дополнительный вывод ошибок:

note: mirlin[1083] exited with preempt_count 1
BUG: scheduling while atomic: mirlin/1083/0x40000002
Modules linked in: g_cdc_ms musb_hdrc nop_usb_xceiv irqk edmak dm365mmap cmemk
Backtrace:
[<c002a5a0>] (dump_backtrace+0x0/0x110) from [<c028e56c>] (dump_stack+0x18/0x1c)
r6:c1099460 r5:c04ea000 r4:00000000 r3:20000013
[<c028e554>] (dump_stack+0x0/0x1c) from [<c00337b8>] (__schedule_bug+0x58/0x64)
[<c0033760>] (__schedule_bug+0x0/0x64) from [<c028e864>] (schedule+0x84/0x378)
r4:c10992c0 r3:00000000
[<c028e7e0>] (schedule+0x0/0x378) from [<c0033a80>] (__cond_resched+0x28/0x38)
[<c0033a58>] (__cond_resched+0x0/0x38) from [<c028ec6c>] (_cond_resched+0x34/0x44)
r4:00013000 r3:00000001
[<c028ec38>] (_cond_resched+0x0/0x44) from [<c0082f64>] (unmap_vmas+0x570/0x620)
[<c00829f4>] (unmap_vmas+0x0/0x620) from [<c0085c10>] (exit_mmap+0xc0/0x1ec)
[<c0085b50>] (exit_mmap+0x0/0x1ec) from [<c0037610>] (mmput+0x40/0xfc)
r9:00000001 r8:80000005 r6:c04ea000 r5:00000000 r4:c0427300
[<c00375d0>] (mmput+0x0/0xfc) from [<c003b5e4>] (exit_mm+0x150/0x158)
r5:c10992c0 r4:c0427300
[<c003b494>] (exit_mm+0x0/0x158) from [<c003cd44>] (do_exit+0x198/0x67c)
r7:c03120d1 r6:c10992c0 r5:0000000b r4:c10992c0
...