Вообщем проблема такая
есть код


модуль загружается нормально: make_call_gate отрабатывает без проблем
при выгрузке (rmmod) получаю Segmentation fault и в логах следующее

если присмотреться к Сall trace, то видим, что destroy_call_gate отрабатывает хорошо (потому как вызывается из sys_delete_module) а ошибка возникает в __unlink_module + 0xa. Причина ошибки видна. Непонятно только, почему если оставить в destroy_call_gate только ret, проблема исчезает, т. е каким то образом код в destroy_call_gate вызывает #PF в __unlink_module()
я в ступоре       

MAKCim, 
Я не уверен флаги которые pushfl восстанавливаются, включают sti ?
А вообще - из юзер-контекста такое делать наврядли в принципе можно   

Это сообщение отредактировал(а) kirjanov - 16.1.2007, 20:22

kirjanov,
Во-во   

чуваки, это модуль ядра

Добавлено @ 21:17 
kirjanov, 
pushl - сохраняет EFLAGS
popfl - соответственно восстанавливает (вместе с IF, который изначально неизвестно, установлен или нет)
естественно CPL <= IOPL в моем случае, иначе было бы другое исключение, не #PF  

Добавлено @ 21:18 

где ты тут user mode увидел?  

Добавлено @ 21:21 

чего? ну и сказал   
естественно, popfl восстанавливает его (eflags) а значит и первоначальное значение IF

MAKCim, 
Я понял что это модуль ядра.

Добавлено @ 04:26 

Сорри, не выспавшася 

MAKCim, 
получается ты вызвал local_irq_disable(), тогда уже лучше вызвать явно local_irq_enable() или c флажками:


Это сообщение отредактировал(а) kirjanov - 17.1.2007, 10:53

kirjanov, 

ты посмотри код local_irq_disable/enable
во-первых - это макрос, который выливается в конструкцию С, что в .S коде неприемлемо
во-вторых, пока там доходят до заветных pushfl, popfl, вызывается много чего ненужного

бывает   

а вообще чего вы приципились к этим флагам - здесь все нормально

MAKCim, 
Не, а про юзер-контекст ты все-таки читкани. Kernel Hacker's Guide, к примеру 

юзер-контекст и Kernel Hacker's Guide??   

Добавлено @ 13:36 
вообще кажется понял, в чем тут лажа
если получится, напишу

Модератор: Название темы должно отражать ее суть! Виноват. Проглядел 


Понятно, что я не модератор этого раздела и не силён в unix, так что для меня суть топика не очень ясна... но проблема в том, что такое название темы тоже ничего не говорит о её содержании. 
Я вообще сначала подумал, что здесь какая-то ерунда и только потом, обратив внимание на статус участника, создавшего тему, понял что эта тема "по делу".

Но всё-таки название советую поменять, тем более что Участнику Клуба это теперь доступно.



Это сообщение отредактировал(а) Дрон - 17.1.2007, 14:06

дорогой Дрон!
Упс ( Oops ) - это термин, или можно сказать профессиональный слэнг разрaботчиков ядра линукс.
Человек в unix/linux kernel  понимающий (чуточку) сразу понимает о чем тема: 
кто-то работает над модулем и получил oops ( присмотрись в первый вложенный текст - в дневнике ядром написано Oops: 0002 [#1])

По сему, считаю, что название темы отражает ее суть.

bilbobagginz, блин, проглядел.
Специально перед тем как писать посмотрел верхние строчки лога (так как предполагал, что это что-то навроде kernel panic), но Oops проглядел 

Признаю. Тема отражает суть, но видимо только для внутреннего потребления. 
Однако вид этой темы на главной странице форума сбивает с толку. Больше я в разделы unix ни ногой 


Это сообщение отредактировал(а) Дрон - 17.1.2007, 14:08

oops тут неприятный   
после него как то все начинает резко неработать  ... модули не выгружаются и пр.

тема закрыта, причину нашел
все банально 

видно до вызова destroy_call_gate в EBX был адрес, который после отработки функции терялся
вообщем детская ошибка
спасибо всем, кто участвовал в обсуждении

MAKCim, 

Да, черт возьми. Кончай шлангом прикидываться.

  
не, просто понятия не сочетаются как то...

Я к тому, что ассемлерный код это нехорошо, потому что архитектурно зависимо. Хотя понятно, что call gate другим ничем не сделаешь   

MAKCim, 
А в репу   
 

Добавлено @ 14:58 
(ну, чтоб начали нормально сочетаться    )

угу

ну, от + я никогда не откажусь   

MAKCim, 
Я в прямом смысле   

да понял я, что в прямом   
только где ты репу зимой найдешь   

Это сообщение отредактировал(а) MAKCim - 17.1.2007, 18:21

Так это ж модуль ядра, вряд ли его M$ портировать будут   

при чем тут M$?
код ядра делится на платформо-независимую часть на С и зависимую (GCC inline assembler + assembler)
т. е тот же модуль может быть полностью независим от архитектурной части железа и идти на всех платформах, где стоит Linux (главное, чтобы ядра были одной стабильной версии), а может быть зависимым от конкретной архитекиуры как в моем случае (IA-32) и поэтому не пойдет ни на чем другом, кроме как на > i386

MAKCim, там же смайл, я пошутил.

ну тогда извини

тогда я не понял смысла фразы, извини конечно  

Вот болтуны...  

Я просто имел в виду не зависимость от архитектуры, а зависимость от ОС.