Re: Read from file fails

[Richard B. Johnson]

On Mon, 3 May 2004, Libor Vanek wrote:

> Hi,
> can anybody help me with reading from file? I've got this code in my module for 2.6.5-mm6:
>
> char buffer[4096];
> ssize_t read;
> file *f;
> f = filp_open("/some/file",O_RDONLY | O_LARGEFILE,0);
> f->f_pos = 0;
> read = vfs_read(f,(char __user *) buffer,4096,&f->f_pos);
>
>
> but here read value is "-14" :-((( any hints?
>

Sure it's -EFAULT. In user-space, you would get a core-dump.


> It seems that file is opened OK (I've tested:
> if (f->f_op->read) {
> 	read = f->f_op->read(file, buf, count, pos);
> }
> and result was the same - so I assume that file is opened OK and
> structure "file f" is filled correctly.

This has become a FAQ and NO If you know what you are doing, you
NEVER need to read files from within the kernel. PERIOD. There are
Hacks that __sometimes__ allow code to get away with it, but
they are only going to work --- sometimes ---.

>
> I need to copy files (yes - I know that kernel shouldn't do this but I REALLY need) and  there is nothing like "sys_copy" and "sys_sendfile" is not exported (which seems strange to me but there is nothing like EXPORT_SYMBOL(sys_sendfile) in fs/read_write.c
>

I will explain for the Nth time. The kernel is a bunch of code
that performs functions on behalf of a process. It does that in
the context of that process. A file descriptor is a number that
belongs to a process. It is worthless without a process with which
to associate. If the kernel were to open a file, who owns the
file descriptor? The kernel isn't a process, it's a big LIBRARY!
So, if you are lucky, you can steal the context from another
unknowing process. This works unless there was a context-switch or
if the process was asleep so it didn't access any files of
its own. It leaves the kernel in a bad state because there
is a wild file-descriptor that nobody owns that will never be
closed because when your cludge closes that file-descriptor, you
probably end up closing STDOUT_FILENO of some important task
that you haven't discovered yet.

The cludges that work involve creating a "kernel thread" which
has a process context. That thread does the file I/O. However,
it's certainly easier to create a user-mode task (program) that
opens your module and, using an ioctl(), sends it anything from
anywhere in the known universe. You can get data from a file or
from anywhere.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips).
            Note 96.31% of all statistics are fiction.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/