Lock Order Reversal

[Darkwolf]

Добрый день!
Чем может быть вызвано подобное сообщение. Появляется через какое-то время полсе загрузки системы:

Код: Выделить всё

May 27 09:15:35 www kernel: lock order reversal:
May 27 09:15:35 www kernel: 1st 0xcd065364 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2579
May 27 09:15:35 www kernel: 2nd 0xc3bb1600 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:283
May 27 09:15:35 www kernel: KDB: stack backtrace:
May 27 09:15:35 www kernel: db_trace_self_wrapper(c0914d32,c2bdea0c,c062e3f5,c061e71b,c0917d0c,...) at db_trace_self_wrapper+0x26
May 27 09:15:35 www kernel: kdb_backtrace(c061e71b,c0917d0c,c2d2b030,c2d2e2f8,c2bdea68,...) at kdb_backtrace+0x29
May 27 09:15:35 www kernel: _witness_debugger(c0917d0c,c3bb1600,c0938bd9,c2d2e2f8,c093885e,...) at _witness_debugger+0x25
May 27 09:15:35 www kernel: witness_checkorder(c3bb1600,9,c093885e,11b,0,...) at witness_checkorder+0x839
May 27 09:15:35 www kernel: _sx_xlock(c3bb1600,0,c093885e,11b,ce974ab0,...) at _sx_xlock+0x85
May 27 09:15:35 www kernel: ufsdirhash_acquire(0,e,c37b5800,cd065304,ce974ab0,...) at ufsdirhash_acquire+0x35
May 27 09:15:35 www kernel: ufsdirhash_remove(c3bac6cc,ce974ab0,ab0,c2bdeaf8,c2bdeaf4,...) at ufsdirhash_remove+0x14
May 27 09:15:35 www kernel: ufs_dirremove(c3ba7550,c3bac5e4,500800c,0,c3ba7550,...) at ufs_dirremove+0x133
May 27 09:15:35 www kernel: ufs_remove(c2bdec30,0,0,0,c3bb2770,...) at ufs_remove+0x6e
May 27 09:15:35 www kernel: VOP_REMOVE_APV(c09900e0,c2bdec30,c3bb2770,c2bdec08,c090ff31,...) at VOP_REMOVE_APV+0xa5
May 27 09:15:35 www kernel: kern_unlinkat(c3821c30,ffffff9c,28a71220,0,0,...) at kern_unlinkat+0x1fb
May 27 09:15:35 www kernel: kern_unlink(c3821c30,28a71220,0,c2bded2c,c08a2a20,...) at kern_unlink+0x2f
May 27 09:15:35 www kernel: unlink(c3821c30,c2bdecf8,c05eeba8,c2bdecc8,c3a2c000,...) at unlink+0x22
May 27 09:15:35 www kernel: syscall(c2bded38) at syscall+0x220
May 27 09:15:35 www kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20
May 27 09:15:35 www kernel: --- syscall (10, FreeBSD ELF32, unlink), eip = 0x287e05bf, esp = 0xbfbfc9ec, ebp = 0xbfbfcab8 ---

Появляется 1 раз, после чего сервер впринципе работает нормально...
З.Ы.: FreeBSD версии 7.3

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[manefesto]

такое ощущение что каррент, отключи в ядре дебаг

[Darkwolf]

А мог я чего лишнего рубануть в ядре (недавно его пересобирал). Конфиг тут http://pastebin.com/XHXWEPcu

[manefesto]

вот это убери

#
# Debugging for use in -current
#
options KDB # Enable kernel debugger support.
#
options DDB # Support DDB.
#
options GDB # Support remote GDB.
#
options DEADLKRES # Enable the deadlock resolver
#
options INVARIANTS # Enable calls of extra sanity checking
#
options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS
#
options WITNESS # Enable checks to detect deadlocks and cycles
#
options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed

И пересобери ядро.
То что у тебя сыпиться это дебаг

[Darkwolf]

ОК. Поставлю на ночь компилиться, завтра отпишу.

[Darkwolf]

А если вырубить dirhash в ядре, на сколько это скажется на производительности?

[Гость]

Прежде чем сообщать о LOR'ах сначала глянь сюда: http://sources.zabbadoz.net/freebsd/lor.html
Твой похож на #261 (cannot deadlock).

[Darkwolf]

Прежде чем сообщать о LOR'ах сначала глянь сюда: http://sources.zabbadoz.net/freebsd/lor.htmlТвой похож на #261 (cannot deadlock).

А я был там и глядел, мало того даже поправил исходник как там написано, и пересобрал ядро. Результат - без изменений. Возможно дело в том, что там обсуждался похожий ЛОР на BSD восьмой версии, а у меня 7.3.
Нет, хотя этот ЛОР не приводит к дезлоку, проблему безусловно хотелось бы решить, а не уходить, скажем, вырубив дебаг, или сам дирхэш в ядре.

[Гость]

там обсуждался похожий ЛОР на BSD восьмой версии, а у меня 7.3.

в то время 7.3 еще не существовал, а изменения из 8-current портировались в 7-stable. Мусье не умеет интерпретировать историю?

ЛОР который не приводит к дедлоку/ливлоку - false positive (как это на русском?), а значит можно игнорировать.

[Darkwolf]

в то время 7.3 еще не существовал

Хм... инетересно, что на http://www.freebsd.org релиз 7.3 был анонсирован одновременно с 8.0, а вышеуказанный lock order reversal (LOR) #261 был зафиксирован спустя два с половиной года после этого

изменения из 8-current портировались в 7-stable.

И что из этого, по Вашим заверениям ufs_dirhash.c в 7.3 должен быть уже переписан, и различаться с восьмой версией, тем не мнее никакие "изменения" его не затронули.

Мусье не умеет интерпретировать историю?

При чём тут история, знание хронологии (и то если они верные ) тут не шибко помогут.

ЛОР который не приводит к дедлоку/ливлоку - false positive (как это на русском?), а значит можно игнорировать.

Раздражает галиматья на экране!

[Гость]

релиз 7.3 был анонсирован одновременно с 8.0, а вышеуказанный lock order reversal (LOR) #261 был зафиксирован спустя два с половиной года после этого

на ЛОР-странице: reported first - 2008-09-30. В то время существовали только 7.0R, 7-stable и 8-current (aka /head).
7.1R (r186660) вышел чуть после 2009-01-01
7.2R (r191715) вышел чуть после 2009-05-01
8.0R (r199625) вышел чуть после 2009-11-21
7.3R (r205405) вышел чуть после 2010-03-21

моя твоя не понимать

по Вашим заверениям ufs_dirhash.c в 7.3 должен быть уже переписан, и различаться с восьмой версией

по svn diff различия в ufs_dirhash.c между 7.3R, 8.0R и 9-current минимальны

Код: Выделить всё

$ svn diff svn://svn.freebsd.org/base/release/{7.3.0,8.0.0}/sys/ufs/ufs/ufs_dirhash.c

Все что нужно уже бэкпортировали.

Раздражает галиматья на экране! :evil:

ну так выруби с помощью conscontrol(8). debug почти всегда подразумевает кучу ненужного вывода. Непонятно зачем ты его трогаешь, если у тя все прекрасно работает.

[Darkwolf]

Хорошо, убедили
По вырубал всё.