Linux 内核中 copy_[to/from]_user() 的锁定
如所述： http://www.kernel.org/doc /htmldocs/kernel-hacking.html#routines-copy 这个函数“可以”睡眠。
那么，在使用这个函数时我是否总是必须进行锁定（例如使用互斥体）或者是否有例外？
我目前正在开发一个模块，并在我的系统上看到了一些内核错误，但无法重现它们。我有一种感觉，他们被解雇了，因为我目前没有锁定 copy_[to/from]_user()。也许我错了，但闻起来似乎与此有关。
我有这样的事情：
static unsigned char user_buffer[BUFFER_SIZE];
static ssize_t mcom_write (struct file *file, const char *buf, size_t length, loff_t *offset) {
ssize_t retval;
size_t writeCount = (length < BUFFER_SIZE) ? length : BUFFER_SIZE;
memset((void*)&user_buffer, 0x00, sizeof user_buffer);
if (copy_from_user((void*)&user_buffer, buf, writeCount)) {
retval = -EFAULT;
return retval;
}
*offset += writeCount;
retval = writeCount;
cleanupNewline(user_buffer);
dispatch(user_buffer);
return retval;
}
这是保存这样做还是我需要在 copy_from_user 运行时锁定它以防止其他访问？
这是一个我从中读取和写入的字符设备，如果收到网络中的特殊数据包，则可以并发访问该缓冲区。
as stated in: http://www.kernel.org/doc/htmldocs/kernel-hacking.html#routines-copy this functions "can" sleep.
So, do I always have to do a lock (e.g. with mutexes) when using this functions or are there exceptions?
I'm currently working on a module and saw some Kernel Oops at my system, but cannot reproduce them. I have a feeling they are fired because I'm currently do no locking around copy_[to/from]_user(). Maybe I'm wrong, but it smells like it has something to do with it.
I have something like:
static unsigned char user_buffer[BUFFER_SIZE];
static ssize_t mcom_write (struct file *file, const char *buf, size_t length, loff_t *offset) {
ssize_t retval;
size_t writeCount = (length < BUFFER_SIZE) ? length : BUFFER_SIZE;
memset((void*)&user_buffer, 0x00, sizeof user_buffer);
if (copy_from_user((void*)&user_buffer, buf, writeCount)) {
retval = -EFAULT;
return retval;
}
*offset += writeCount;
retval = writeCount;
cleanupNewline(user_buffer);
dispatch(user_buffer);
return retval;
}
Is this save to do so or do I need locking it from other accesses, while copy_from_user is running?
It's a char device I read and write from, and if a special packet in the network is received, there can be concurrent access to this buffer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您需要锁定当且仅当您复制到或复制的内核端数据结构可能会消失，否则您应该锁定该数据结构。
You need to do locking iff the kernel side data structure that you are copying to or from might go away otherwise - but it is that data structure you should be taking a lock on.
我猜你的函数
mcom_write是一个 procfs 写入函数（或类似的函数），对吗？在这种情况下，您很可能正在写入 procfs 文件，您的程序将被阻止，直到mcom_write返回，因此即使copy_[to/from]_user< /code> 睡眠，你的程序不会改变缓冲区。你还没有说明你的程序是如何工作的，所以很难说什么。如果您的程序是多线程的，并且一个线程写入，而另一个线程可以更改其数据，那么是的，您需要锁定，但在用户空间程序的线程之间而不是内核模块之间。
如果您有一个线程写入，那么您对 procfs 文件的写入将被阻止，直到
mcom_write完成，因此不需要锁定，并且您的问题出在其他地方（除非此函数有其他问题） ，但不适用于copy_from_user）I am guessing your function
mcom_writeis a procfs write function (or similar) right? In that case, you most likely are writing to the procfs file, your program being blocked untilmcom_writereturns, so even ifcopy_[to/from]_usersleeps, your program wouldn't change the buffer.You haven't stated how your program works so it is hard to say anything. If your program is multithreaded and one thread writes while another can change its data, then yes, you need locking, but between the threads of the user-space program not your kernel module.
If you have one thread writing, then your write to the procfs file would be blocked until
mcom_writefinishes so no locking is needed and your problem is somewhere else (unless there is something else that is wrong with this function, but it's not withcopy_from_user)