Summary: | modprobe race during early boot | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Ivan Zakharyaschev <imz> |
Component: | module-init-tools | Assignee: | Alexey Gladkov <legion> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P2 | CC: | hsvhome, ldv, mike, shrek, silicium, vsu |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux |
Description
Ivan Zakharyaschev
2008-02-13 10:35:40 MSK
This sometimes happen during boot, because locking in modprobe does not work until the root filesystem is remounted read-write, and udevd (which also triggers lots of concurrent modprobe calls) now starts when the root fs is still readonly. One possible solution is to replace fcntl() locking in modprobe with flock() - these locks are purely local anyway, and flock(fd, LOCK_EX) is possible even when fd was opened with O_RDONLY. BTW, old modutils used flock() there. A comment by vsu someone might find useful -- https://bugzilla.altlinux.org/show_bug.cgi?id=14411#c1 : the uhci_hcd problem is due to races between concurrent modprobe invocations. *** Bug 15550 has been marked as a duplicate of this bug. *** (In reply to comment #3) > *** Bug 15550 has been marked as a duplicate of this bug. *** > At last std-def kernel i no see correspond error messages. The bug is FIXED? fixed (In reply to comment #5) > fixed где fixed, каким коммитом? это было давно и насколько я помню не в module-init-tools (In reply to comment #7) > это было давно и насколько я помню не в module-init-tools Если проблема не исправлена в module-init-tools, то она ещё не исправлена, и всплывёт в аналогичной ситуации. (В ответ на комментарий №6) > где fixed, каким коммитом? Исправлено в ядре, начиная с 2.6.25: commit c9a3ba55bb5da03fc7d707709a7fe078fe1aa0a0 Author: Rusty Russell Date: Tue Jan 29 17:13:18 2008 -0500 module: wait for dependent modules doing init. There have been reports of modules failing to load because the modules they depend on are still loading. This changes the modules to wait for a reasonable length of time in that case. We time out eventually, because there can be module loops or broken modules. Изначально проблема возникла из-за того, что при выполнении системного вызова init_module() вызывается функция инициализации модуля, которая в общем случае может выполняться сколь угодно долго, и в это время не блокируются другие вызовы init_module(), однако модуль ещё не инициализирован полностью, и экспортируемые им символы не могут использоваться другими модулями. Блокировка в modprobe устраняла именно эту проблему - зависимые модули не загружались, пока не снималась блокировка с базового модуля (после завершения его инициализации). При использовании ядра >= 2.6.25, если при загрузке модуля обнаруживается, что какие-либо из необходимых для него символов предоставляются модулями, которые ещё не были полностью инициализированы, вместо немедленной выдачи ошибки ожидается завершение инициализации требуемых модулей (максимум 30 секунд). Блокировка на уровне modprobe в этом случае не требуется (и в последних версиях module-init-tools код, выполнявший эту блокировку, был удалён). |