Безопасен ли е __alloc_pages_slowpath() за повторно влизане или не?

Може ли извикването на __alloc_pages_slowpath() да оцелее след прекъсване на устройството, което също прави повикване на __alloc_pages_slowpath() или второто извикване поврежда първото?

Виждам програмно извикване read(2) на обикновен файл на файлова система XFS. Проследяването на стека на ядрото показва, че в крайна сметка __alloc_pages_slowpath() се извиква, след което се случва e1000e IRQ, което също в крайна сметка извиква __alloc_pages_slowpath() и след това почти веднага се появява лог съобщение "fooprog: неуспешно разпределение на страници. поръчка:0, режим:0x4020".

Цялото трасиране на стека може да се види тук: https://gist.github.com/790577


linux linux-kernel driver reentrancy irq
person Community    schedule 21.01.2011    source източник

Отговори (1)


arrow_upward
1
arrow_downward

„fooprog: неуспешно разпределение на страници. order:0, mode:0x4020“ се дължи на проблем с драйвера e1000e. Задаването на vm.min_free_kbytes да удвои текущата си стойност ги предотвратява. __alloc_pages_slowpath() вероятно е безопасен за повторно влизане.

Актуализация: (1) „нормално поведение“ е да имате огромни следи на стека, отпечатани във вашия системен журнал на ядрото на Linux, когато драйвер на мрежово устройство се опита да разпредели страница и установи, че не може. (2) някой изпрати корекция и в продължение на шест месеца тя беше игнорирана, докато не ги помолих любезно да проследят въвеждането на корекцията. След това KVM/qemu virtio мрежата спря да се заключва, когато паметта на виртуалните машини свърши. (3) алтернативите на Linux за съжаление са по-лоши за мен, за да върша реална работа.

person Community    schedule 24.01.2011
comment
Предлагам да приемем вашия отговор като „отговор“, така че този въпрос да бъде премахнат от списъка с въпроси без отговор. :) - person sarnold; 31.01.2011