Kernel Module, ioctl, синхронизация

Внутри модуля обычно есть все необходимые блокировки.

lock_kernel() в начале ядерного ioctl, unlock_kernel() - в конце

Наверное не так. Если ты вызываешь некий syscall из разных потоков, и передашь указатель на данные, которые модифицирует один поток, а другой читает, то да, коллизия возможна.

Если передаются независимые данные, то это безопасно. В модуле, обслуживающем вызов должны быть все необходимые блокировки на свои внутренние структуры.

и подскажите еще пожалуйста, как правильно подключить mutex.h (Debian stable)

Спасибо за ответ, именно что используется одна общая структура данных, хранящаяся в модуле, поэтому я и опасаюсь коллизий. А как в таких случаях лучше выполнять блокировку (mutex, futex, spinlock или что-то еще)?

#include <linux/mutex.h>

spinlock

#include <linux/mutex.h> - такой вариант не проходит почему-то.

Сам по себе файл mutex.h находится в пакете linux-headers-.....deb, и путь его установки зависит от версии пакета (что-то вроде /usr/src/linux-headers-...common/include/linux). В /usr/include/linux только futex.h. Как в этом случае правильно разрулить пути, чтобы собиралось с различными версиями ядра?

Ну вот, разработчики так старательно выпиливали BKL, а ты его предлагаешь с ходу юзать.

По сабжу: если частота чтения превышает частоту записи, то SpinLock, иначе думать дальше=)

_модуль_ ядра использует заголовочные файлы того ядра, под который он собирается. они находятся в дереве исходников этого ядра.

ЗЫ: AFAIK, ioctl и так вызывается под блокировкой. и это проблема. для её решения добавили новый обработчик unlocked_ioctl, который не требует блокировок самим ядром, а решает сам, блокировать ему что-нибудь или нет. но это устаревшая информация, может уже там всё втихаря поменяли :)

Я рекомендую тебе определиться с путем разработки модуля для ядра. Ты либо разрабатываешь его в стиле debian-way, либо generic-way.

В первом случае тебе и правда надо будет пакет linux-headers-<VERSION> Во втором случае тебе надо просто каталог с исходниками ядра.

В обеих случаях собирать модуль надо «хитро» :) Вот пример моего Makefile:

$ cat Makefile
obj-m := fakedev.o

all:
        make -C /usr/src/linux-headers-`uname -r` M=`pwd` modules

.PHONY: clean

clean: 
        make -C /usr/src/linux-headers-`uname -r` M=`pwd` clean

> разработчики так старательно выпиливали BKL

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

Да пусть лучше вообще в один поток работает, что уж там... Юзер подождёт.

Ты тролль или реально такой?

а накой при этом структуру file_operations ломать, ты сможешь внятно объяснить?

Это, мягко говоря, отдельный вопрос. Ссылку на багрепорт в студию.

wtfigo? можешь спать - мьютекс, не можешь - спинлок