File handling in a kernel module. What is the appropriate way to 'seek' in a file? I could not find a sys_seek() function (such as sys_read()). Or, is it better only to use the VFS function API?
The question How to read/write files within a Linux kernel module? does not handle input stream navigation, i.e. there is no reference to tell()/seek() of any kind.
seek functionality in the kernel space can be achieved by vfs_llseek function:
loff_t vfs_llseek(struct file *file, loff_t offset, int whence);
The function returns resulted offset or negative value in case of error.
Related
I am newbie for Linux kernel, I cloned the Linux source from its repo on GitHub. I cannot find the file sys/mount.h nor the mount function.
Do you know where is this file located in source code? Where can I find its implementation?
If you don't know where a system call is implemented in the kernel, there's a general sequence of steps you can use to find it. You will need to download the kernel source to your machine.
Begin by finding the number of parameters the syscall requires. eg. mount(2) requires five parameters.
Since mount(2) requires 5 parameters, search for SYSCALL_DEFINE5(mount in the kernel source:
grep -nr 'SYSCALL_DEFINE5(mount'
This will take a while to run, but it will eventually find:
./fs/compat.c:92:COMPAT_SYSCALL_DEFINE5(mount, const char __user *, dev_name,
./fs/namespace.c:3026:SYSCALL_DEFINE5(mount, char __user *, dev_name, char __user *, dir_name,
So, the syscall you're looking for is located at in ./fs/namespace.c on line 3026. (I'm using Linux 4.19.99, so the line number will probably be different on your kernel.)
I recently wrote a module implementing these functions.
What is the difference between the two? From my understanding, the copy_..._user functions are more secure. Please correct me if I'm mistaken.
Furthermore, is it a bad idea to mix the two functions in one program? For example, I used simple_read_from_buffer in my misc dev read function, and copy_from_user in my write function.
Edit: I believe I've found the answer to my question from reading fs/libfs.c (I wasn't aware that this was where the source code was located for these functions); from my understanding the simple_...() functions are essentially a wrapper around the copy_...() functions. I think it was appropriate in my case to use copy_from_user for the misc device write function as I needed to validate that the input matched a specific string before returning it to the user buffer.
I will still leave this question open though in case someone has a better explanation or wants to correct me!
simple_read_from_buffer and simple_write_to_buffer are just convenience wrappers around copy_{to,from}_user for when all you need to do is service a read from userspace from a kernel buffer, or service a write from userspace to a kernel buffer.
From my understanding, the copy_..._user functions are more secure.
Neither version is "more secure" than the other. Whether or not one might be more secure depends on the specific use case.
I would say that simple_{read,write}_... could in general be more secure since they do all the appropriate checks for you before copying. If all you need to do is service a read/write to/from a kernel buffer, then using simple_{read,write}_... is surely faster and less error-prone than manually checking and calling copy_{from,to}_user.
Here's a good example where those functions would be useful:
#define SZ 1024
static char kernel_buf[SZ];
static ssize_t dummy_read(struct file *filp, char __user *user_buf, size_t n, loff_t *off)
{
return simple_read_from_buffer(user_buf, n, off, kernel_buf, SZ);
}
static ssize_t dummy_write(struct file *filp, char __user *user_buf, size_t n, loff_t *off)
{
return simple_write_to_buffer(kernel_buf, SZ, off, user_buf, n);
}
It's hard to tell what exactly you need without seeing your module's code, but I would say that you can either:
Use copy_{from,to}_user if you want to control the exact behavior of your function.
Use a return simple_{read,write}_... if you don't need such fine-grained control and you are ok with just returning the standard values produced by those wrappers.
Is it possible to acquire the struct fuse_file_info* fi in the function truncate()? Why is it not there in the first place?
int truncate(const char* path, off_t size)
I'm storing my file descriptor in the file handler, fh, of the fuse_file_info structure. The function open() appears to be called beforehand so that structure is created for the file. The description of fh is: "File handle. May be filled in by filesystem in open(). Available in all other file operations".
(As a last resort I'm thinking of having a structure to store this information, saved into a hash map, and then use the file handler to store the key. This would allow me to search the structure, using the path, in order to find the respective file descriptor.)
Note: I'm actually using jnr-fuse but since it mimics libfuse I'm not asking specifically for it; what works for one should (sort of) work for the other.
Why is it not there in the first place?
Because of implementation of truncate in the Linux kernel. You can see signature here.
I read the book "Linux Kernel Development", and find some functions that make me confused, listed as bellow:
struct page *alloc_pages(gfp_t gfp_mask, unsigned int order)
void __free_pages(struct page *page, unsigned int order)
unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order)
void free_pages(unsigned long addr, unsigned int order)
The problem is the use of the two underline in the function name, and how the function pairs.
1. when will the linux kernel uses two underline in its function name?
2. why alloc_pages is paired with __free_pages, but not free_pages?
As you can notice:
alloc_pages() / __free_pages() takes "page *" (page descriptor) as argument.
They are ususally used internally by some infrastrcture kernel code, like page fault handler, which wish to manipulate page descriptor instead of memory block content.
__get_free_pages() / free_pages() takes "unsigned long" (virtual address of memory block) as argument
They could be used by code which wish to use the memory block itself, after allocation, you can read / write to this memory block.
As for their name and double underscore "__", you don't need to bother too much. Sometimes kernel functions were named casually without too much consideration when they were first written. And when people think of that the names are not proper, but later those functions are already used wildly in kernel, and kernel guys are simply lazy to change them.
in source/arch/x86/kernel/msr.c, the msr_open callback for the character device uses the following construct to extract the minor number of the character device file used:
static int msr_open(struct inode *inode, struct file *file)
{
unsigned int cpu = iminor(file_inode(file));
[...]
}
My question is:
Why not directly call iminor with the first argument of the function, like:
unsigned int cpu = iminor(inode);
The construct is used in other callbacks (e.g. read and write) as well,, where the inode is not passed as an argument, so I guess this is due to copy/paste, or is there a deeper meaning to it?
An inode is a data structure on a traditional Unix-style file system such as UFS or ext3. An inode stores basic information about a regular file, directory, or other file system object.
- http://www.cyberciti.biz/tips/understanding-unixlinux-filesystem-inodes.html
Same deal.