удаление модулей ядра

А ядро собрано с поддержкой форсированной выгрузки модулей?

Используй KVM :)

> Я пытаюсь выгрузить этот сбойнутый модуль

А смысл? Сбойное -- всё ядро, а не отдельный модуль, они ж в одном адресном
пространстве работают.

> Помогите пожалуйста, как удалить сбойнутый модуль,

Еще раз: сбойное -- всё ядро. Ваш модуль вполне мог подпортить что-нибудь,
к нему не относящееся.

> а то запарило уже менять имена одному и тому же модулю для его отладки.

Результаты такой "отладки" можно смело отправлять в /dev/null.

>Результаты такой "отладки" можно смело отправлять в /dev/null. Поподробнее пожалуйста на этом месте. Про общее адресное простарнство я уже понял - прийдётся перезапустить систему(а именно ядро), хотя я при конфигурации ядра встречал пунктик про рестарт ядра без рестарта системы. Есть ли вообще такая возможность? А что качается сбойнутости ядра, то система дальше функционирует на ура.

> А смысл? Сбойное -- всё ядро, а не отдельный модуль, они ж в одном адресном пространстве работают.

Модуль может спокойно обратиться мимо vma и получить oops. Ядро продолжает работать спокойно.

> Результаты такой "отладки" можно смело отправлять в /dev/null.

Своё в /dev/null что угодно можешь отправлять. Тебя волнует, как другие отлаживаются?

> Модуль может спокойно обратиться мимо vma и получить oops. Ядро продолжает
> работать спокойно.

Пойдите на LKML и порассказывайте такие басни.

> Своё в /dev/null что угодно можешь отправлять.

Отправляю, не волнуйтесь.

> Тебя волнует, как другие отлаживаются?

Если мне не прийдется использовать/сопровождать поделие, которое так
"отлаживали", -- нет. Проблемы афроамериканцев шерифа не интересуют,
так сказать.

> встречал пунктик про рестарт ядра без рестарта системы.

kexec, что ли?

> А что качается сбойнутости ядра, то система дальше функционирует на ура.

Ага, особенно rmmod. Рекомендую подумать на тему "почему на LKML всегда просят
показать _самый первый_ Oops."


Вы вот что скажите -- зачем Вам понадобилось отлаживать на настоящем железе,
а не в qemu/UML/etc. Это что у Вас, драйвер какой-то?

> Модуль может спокойно обратиться мимо vma и получить oops.

А может взять какой-нибудь lock (и не успеть освободить), может slab
испортить, и еще много чего интересного сделать.

>> Модуль может спокойно обратиться мимо vma и получить oops. Ядро >> продолжает работать спокойно.

> Пойдите на LKML и порассказывайте такие басни.

Какие басни? Что во время разработки модуля человеки естественным образом делают ошибки?

По существу: что такого фатального случится с ядром, если бажный модуль попытается прочитать из отсутствующей области памяти?

Если верить местным товарищам-программистам, то вообще ядерный реактор взорваться может. Если бы, да "бы" мешает. Какое это имеет отношение к процессу обучения/разработки? Ну встанет колом ядро у автора поста после некоторого времени, перегрузит машину, что с того? Может, вообще после каждого OOPS удалять исходники и переписывать их заново?

Dselect хочет сказать что поведение ядра после загрузки кривого модуля непредсказуемо.

Собстно, вопрос, я так понимаю, в том после каких ошибок в модуле надо ребутать ядро а после каких можно и не ребутать. Что сами разрабы ядра на этот счёт говорят? :).

Я бы для тестов держал пару-тройку виртуальных машин и, пока на одной тестируется, другая ребутается после oops или паники :).

> По существу: что такого фатального случится с ядром, если бажный модуль
> попытается прочитать из отсутствующей области памяти?

Сценарий: берём foo_lock, начинаем чего-нибудь читать, а тут -- Oops.
Вопрос: кто и как теперь foo_lock отмыкать-то будет?

> Ну встанет колом ядро у автора поста после некоторого времени,
> перегрузит машину, что с того?

Это если повезёт. А если не повезёт, то еще долго в полудохлом состоянии
будет брыкаться. И Oops'иться в каких-то совершенно левых местах. Или
тихонько-подленько портить какой-нибудь кеш (dcache, etc).

Для такого "везения" необходим определённый характер работы модуля. Если модуль падает где-то на операции чтения, то ничего не запортится. Утверждать что-либо, не видя исходники, смысла не имеет.

> Утверждать что-либо, не видя исходники, смысла не имеет.

Медитировать каждый раз над исходником, чтоб сообразить, нужно ли
перезапустить ядро или нет, это пустая трата времени. Перезапустить
qemu -- оно проще, быстрее и надёжнее.

Зачем что-то выгружать. Специально для Вас придумали кучу виртуальных машиин ) Вообще надо аккуратно писать..

Просто так OOPS не выпадает. Если выпадает - значит действительно OOPS. Ловить непонятные баги ради секундной лени ребутнуть виртуалку - дурное занятие.

> Вообще надо аккуратно писать..

Правильный совет, но совершенно бесполезный. Ошибки всегда бывают -- начиная
от очепяток и заканчивая неправильным пониманием того, как работает какая-нибудь
подсистема.

> Вопрос: кто и как теперь foo_lock отмыкать-то будет? 

про lockdep слышали?
просмотрите цепочку вызовов начиная со spin_lock()
spin_lock() -> _spin_lock() -> spin_acquire() -> lock_acquire() -> __lock_acquire()
особое внимание обратите на __lock_acquire()