A message for Linux.com registered users: We are in the process of making changes to the Linux forums. Starting Monday, 8/13/18 at 6:00 PM PT, you will be unable to access the forums. They will re-launch as soon as possible on Wednesday, 8/15/18 with new features and improved functionality. Thank you for your patience and stay tuned for the new improved forums.
Contents of the file descriptor's arg->buf vector.
General Information: I'm trying to find the contents of the file being read and copied into user space within the kernel through the process of the read() system call.
Playing around with the file I/O of the Linux kernel, I traced the general call-route to find where exactly the contents of the file's information is copied back to user context to the program which is effectively calling read().
The C code is pretty general, I used the system calls open(), read(), close(), rather than the usual fscanf varieties mainly because I wanted to trace the read() call. The program is reading in the data file which contains a series of numbers.
123456789012... and so forth.
Now to trace the read call using kernel debugging messages to verify the routes and branching.
Tracing the read() call, it takes me to the read system call definition in the read_write.c file within the /fs/ directory.
Where is calls the vfs_read method.
VFS_Read subsequently calls the do_sync_read method.
Which then calls the aio_read method of the file operations field which takes us to generic_aio_read within the /mm/filemap.c file.
Which then calls the generic_file_read method at:
Which appears to use the file_read_actor method as the actual aspect of this process in copying the information of the file into user space, detailed at this line:
Given the structure of the copy_to_user method, the arguments are generally.
copy_to_user(src, dest, size)
Therefore the source(ie, file data) is in the file descriptors->arg->buf structure which just seems to be a standard buffer, so if we were to inspect the contents of this buffer(as in, we print out the contents of each index to the dmesg buffer) I would expect to see the individual bytes of information contained in the file.(ie, 123456..)
The results I got were quite different, they were a long the lines of:
arg.buf = \x1c
arg.buf = \xffffffdb
arg.buf = \x7f
arg.buf = &
arg.buf = G
The code that prints this out is pretty basic:
printk(KERN_DEBUG "arg.buf[%d] = %c\n",i,desc->arg.buf[i]);
I thought maybe those who had more experience in kernel development may be able to answer as to why the output does not reflect the contents of the file.(Mind you, the actual program does read in the proper data from the file, but I can't seem to find that data within the kernel's read system call process)