I have wrote a kernel module, It is a Character device driver something like this Link .The driver has an internal structure like:
struct {
str[500];
}channelData;
static channelData chData[4];
So I have a multi-threaded application which uses this driver, I currently use this driver in following way:
typedef struct
{
int channelId;
int len;
char arg[100];
} driverArgs;
class DevDrv{
static void STR_READ(int channelId, char *data);
static void STR_SEND(int channelId, char *data,int len);
};
void DevDrv::STR_READ(int channelId, char *data)
{
driverArgs arg= {-1,0, {0}};
arg.channelId = channelId;
ioctl(mfilehandler,IOCTL_STR_READ,&arg);
memcpy(data,arg.arg,arg.len)
}
void DevDrv::STR_SEND(int channelId, char *data,int len)
{
driverArgs arg= {-1,0, {0}};
arg.channelId = channelId;
arg.len=len;
memcpy(arg.arg,data,len);
ioctl(mfilehandler,IOCTL_STR_SEND,&arg);
}
So, The question is if 4 threads in my application call these functions to read or write into their own ChannelId like this to read from or write into driver:
thread1:
DevDrv::STR_READ(0,&localdst);
thread2:
DevDrv::STR_READ(1,&localdst);
thread3:
DevDrv::STR_READ(2,&localdst);
thread4:
DevDrv::STR_READ(3,&localdst);
is there data-racing or something like that happen?
Your channelData
structure is not guaranteed to be cache-aligned, so unless you explicitly synchronize chData
, you're still subject to data races.
Here's a sketch of a race:
In this scenario, those few bytes are stale on CPU 0, because they were overwritten by CPU 1, and CPU 0 wasn't aware.
It wasn't aware, because there wasn't a memory barrier telling it its cache might be stale.
Now, in many instances, a system call triggers a memory barrier, BUT it is not guaranteed.
Your userspace program is fine, and a character device is the canonical way to communicate with a kernel module, but your kernel module has to synchronize properly. Even the example in your link seems to be trying to be very introductory and does things like Device_Open++
without using atomics.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.