Contents of the file descriptor's arg->buf vector.

Sbadams

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.

http://lxr.linux.no/linux+v3.9.4/fs/read_write.c#L488

Where is calls the vfs_read method.

http://lxr.linux.no/linux+v3.9.4/fs/read_write.c#L365

VFS_Read subsequently calls the do_sync_read method.

http://lxr.linux.no/linux+v3.9.4/fs/read_write.c#L339

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.

http://lxr.linux.no/linux+v3.9.4/+code=generic_file_aio_read

Which then calls the generic_file_read method at:

http://lxr.linux.no/linux+v3.9.4/mm/filemap.c#L1081

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:

http://lxr.linux.no/linux+v3.9.4/mm/filemap.c#L1322

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[0] = \x1c

arg.buf[1] = \xffffffdb

arg.buf[2] = \x7f

arg.buf[3] = &

arg.buf[4] = 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)

Sbadams

Shameless bump for help.