Bug 12730

Summary: Вызывает зависание SMP-системы
Product: Sisyphus Reporter: Roman Savochenko <rom_as>
Component: mbmonAssignee: viy <viy>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: critical    
Priority: P2 CC: aen, mike, stalker, vsu
Version: unstable   
Hardware: all   
OS: Linux   
Attachments:
Description Flags
mbmon_test.cpp none

Description Roman Savochenko 2007-09-09 01:53:27 MSD
Дистрибутив: ALT4.0
Система: AMD Athlon 64 x2 3600+, ASUS M2NPV-VM
Режим: периодический вызов из другого приложения, через popen().
Приводит к стабильному зависанию системы в промежутке вызова от 1-30мин при 
периодическом вызове с периодом от 0.1-1сек.
На системах с одним процессором/ядром такой проблемы не выявлено.
Comment 1 viy 2007-09-09 15:28:12 MSD
Вы testcase не бросите?

У меня похожая машина, хочу воспроизвести.

Кр. того, из описания не понятно, вы popen() периодически дергаете и тучу этих
mbmon плодите?

достаточно 1 запустить.
Comment 2 Roman Savochenko 2007-09-17 13:33:10 MSD
(In reply to comment #1)
> Вы testcase не бросите?
У меня это исполняется в рамках SCADA-системы OpenSCADA.
Отделить попробую, в ближайшее время.

> У меня похожая машина, хочу воспроизвести.
> Кр. того, из описания не понятно, вы popen() периодически дергаете и тучу 
этих
> mbmon плодите?
> достаточно 1 запустить.
Я не пложу, я периодически вызываю одиночный запрос mbmon, т.е mbmon после 
запроса завершается.
Comment 3 Roman Savochenko 2007-09-17 13:34:38 MSD
Команда вызова у меня: mbmon -r -c 1
Comment 4 Sergey Vlasov 2007-09-17 16:25:26 MSD
То, что делает mbmon (прямой доступ к портам, минуя все драйверы), вряд ли можно
сделать надёжным - слишком много возможностей для конфликтов с другими
программами, обращающимися к тем же устройствам. Например, функция
pci_conf_read() из pci_pm.c потенциально опасна - поскольку доступ к
конфигурации PCI не является атомарным (требуется 2 операции - запись в регистр
адреса и чтение данных по выбранному адресу), выполнение этой функции может
нарушить работу другого процесса (в том числе кода ядра), параллельно
выполняющегося на другом процессоре и обращающегося к тем же регистрам. В
однопроцессорной системе такие проблемы могут не проявляться, поскольку в этом
случае нет возможности параллельного выполнения кода пользовательского процесса
(mbmon) и кода ядра.

Могу посоветовать настроить lm_sensors; правда, в этом случае тоже возможны
аналогичные конфликты, но уже с кодом BIOS, который в некоторых случаях
обращается к сенсорам - эта проблема пока не решается нормальным образом.
Comment 5 viy 2007-09-18 16:33:37 MSD
гм. тогда ничем не помогу :(
Comment 6 viy 2007-09-27 16:54:10 MSD
закрою, так как ничего не могу сделать.
Comment 7 Roman Savochenko 2007-09-29 00:32:45 MSD
Created attachment 2213 [details]
mbmon_test.cpp

Исходник тестовой программки, которая вызывает mbmoon через popen с
периодичностью 100мс.
Как минимум уже один раз система повисла при фоновой работе этой программки,
после часа работы.
Comment 8 Roman Savochenko 2007-09-29 00:36:05 MSD
(In reply to comment #4)
> Могу посоветовать настроить lm_sensors; правда, в этом случае тоже возможны
> аналогичные конфликты, но уже с кодом BIOS, который в некоторых случаях
> обращается к сенсорам - эта проблема пока не решается нормальным образом.

Спасибо за информацию. С mbmon было проще в реализации и настройке, но раз 
так, то добавлю поддержку lm_sensors.
Comment 9 Roman Savochenko 2011-07-10 20:09:56 MSK
Переоткрываю ошибку, поскольку фактически это критическая crash уязвимость ядра.
Comment 10 viy 2011-07-10 22:25:15 MSK
можно вылечить гильотиной, т.е. удалить из Сизифа. апстрим mbmon не развивает.
Comment 11 Roman Savochenko 2011-07-10 22:42:05 MSK
(В ответ на комментарий №10)
> можно вылечить гильотиной, т.е. удалить из Сизифа. апстрим mbmon не развивает.
Можно, только выглядеть это будет как удаление локального эксплоита из дырявой системы.
Comment 12 viy 2011-07-10 22:48:56 MSK
#50157 AWAITING #1 sisyphus del=xmbmon
Comment 13 AEN 2011-07-11 05:03:31 MSK
(В ответ на комментарий №9)
> Переоткрываю ошибку, поскольку фактически это критическая crash уязвимость
> ядра.

Вешайте багу на ядро.
Comment 14 Sergey Vlasov 2011-07-11 19:43:17 MSK
(В ответ на комментарий №13)
> Вешайте багу на ядро.

Не надо ничего вешать на ядро — проблема как раз в том, что mbmon лезет в порты мимо ядра.
Comment 15 Roman Savochenko 2011-07-11 19:49:41 MSK
(В ответ на комментарий №14)
> Не надо ничего вешать на ядро — проблема как раз в том, что mbmon лезет в порты
> мимо ядра.
Тогда будет самое правильное убрать его из репозитория, как минимум из P6, как потенциально опасное, не поддерживаемое и некорректно работающее с низкоуровневым API.
Comment 16 Michael Shigorin 2011-07-12 02:53:07 MSK
(In reply to comment #7)
> Как минимум уже один раз система повисла при фоновой работе этой программки,
> после часа работы.
А это у тебя железо стреляться вполне может.  IPMI BMC тоже так умеет...
Comment 17 Roman Savochenko 2011-07-12 08:11:27 MSK
(В ответ на комментарий №16)
> (In reply to comment #7)
> > Как минимум уже один раз система повисла при фоновой работе этой программки,
> > после часа работы.
> А это у тебя железо стреляться вполне может.  IPMI BMC тоже так умеет...
В смысле?
Я на этом своём железе уже чётко и неоднократно заметил закономерность. Только mbmon работает часов 5 - жди зависаний с теме-же симптомами. При этом без mbmon и с lm_sensors машина работает сутками. И вот недавно, не запуская специально mbmon, я был удивлён получив характерное зависание. Как оказалось была несколько сломана инсталляция libsensors и моя программа автоматически начала использовать mbmon, а результат не стал долго себя ждать.
Можно конечно попробовать и на другой машине.
Comment 18 Roman Savochenko 2011-07-12 08:25:24 MSK
Возможно mbmon совсем можно не удалять, а достаточно будет установить конфликт с libsensors.

В ближайшее время попробую погонять тест mbmon при полном отсутствии libsensors.