userspace buffer in read/write system call

userspace buffer in read/write system call

[UZAIR LAKHANI]

Hello All,

Suppose I want to implement read/write file operations
of a simple file system. Consider the read system
call. The file system's struct file_operations
function that will be called is this

ssize_t (*read) (struct file *, char *, size_t, loff_t
*);

The char * in the arguments of read is a user-space
buffer pointer. Suppose I don't want to send this
buffer that we have got to the generic_file_read
function or some other function and instead want to
create a new buffer and send it to the
generic_file_read (or other) function. Then copy this
buffer that we have sent to the generic_file_read to
the actual buffer that we had received so that the
call can be completed and the buffer received is
filled.

Consider what I am doing now is

static ssize_t
foo_read(file_t *file, char *buf, size_t count, loff_t
*ppos)
{
	...
	char __user local_buffer[10];	//TODO
	count = 10;			// setting a new count	

	// read_XXX below is to be taken as a function that 
	// will do read for us e.g. generic_file_read can be 
	// such a function
	err = read_XXX( file, local_buffer, count, ppos);

	// now copy local_buffer into buf 
	...

	// the err is -14 or BAD ADDRESS
	return err;
}

Any help regrading this is welcome.

Thanks,
Uzair Lakhani,
Karachi, Pakistan.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: userspace buffer in read/write system call

[Dave Kleikamp]

On Fri, 2006-05-19 at 07:01 -0700, UZAIR LAKHANI wrote:
> Hello All,
> 
> Suppose I want to implement read/write file operations
> of a simple file system. Consider the read system
> call. The file system's struct file_operations
> function that will be called is this
> 
> ssize_t (*read) (struct file *, char *, size_t, loff_t
> *);
> 
> The char * in the arguments of read is a user-space
> buffer pointer. Suppose I don't want to send this
> buffer that we have got to the generic_file_read
> function or some other function and instead want to
> create a new buffer and send it to the
> generic_file_read (or other) function. Then copy this
> buffer that we have sent to the generic_file_read to
> the actual buffer that we had received so that the
> call can be completed and the buffer received is
> filled.

If you want to pass a kernel address to a function that takes a user
address, you need to call set_fs(KERNEL_DS) first.  A few examples are
in fs/nfsd/vfs.c, such as:

        oldfs = get_fs(); set_fs(KERNEL_DS);
        err = inode->i_op->readlink(dentry, buf, *lenp);
        set_fs(oldfs);
-- 
David Kleikamp
IBM Linux Technology Center

Re: userspace buffer in read/write system call

[Bryan Henderson]

>The char * in the arguments of read is a user-space buffer pointer.

It isn't actually a pointer at all.  It's an address.  People often run 
into trouble like yours because they don't grasp that.  "char *" is an 
unfortunate choice of data type for this because it obscures that point 
and prevents the compiler from detecting errors.  Some kernel code uses 
"long" instead, which is a much better choice.  If Linux were like that, 
your code would have failed to compile rather than give you EFAULT (or 
worse) at run time.

Actually ISTR Linux did get in the past few years some kind of typing 
scheme for user space addresses -- but we don't see it here.  Does anyone 
know about that?

A pointer is something that points to a variable.  The usual 
implementations of C use memory to represent a variable and the address in 
some particular address space of that memory to represent a pointer.  A 
more sophisticated implementation might include address space information 
in the pointer and then you truly could have a "char *" argument to 
->read() and read into a user space buffer the same way you read into a 
kernel buffer.

--
Bryan Henderson                     IBM Almaden Research Center
San Jose CA                         Filesystems

Re: userspace buffer in read/write system call

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 2226 bytes --]

On Fri, May 19, 2006 at 07:01:48 -0700, UZAIR LAKHANI wrote:
> Hello All,
> 
> Suppose I want to implement read/write file operations
> of a simple file system. Consider the read system
> call. The file system's struct file_operations
> function that will be called is this
> 
> ssize_t (*read) (struct file *, char *, size_t, loff_t
> *);
> 
> The char * in the arguments of read is a user-space
> buffer pointer. Suppose I don't want to send this
> buffer that we have got to the generic_file_read
> function or some other function and instead want to

Particularly to generic_file_read you **DO** want to pass it --
generic_file_read takes a user-space address just like the read file
operation. In fact some filesystems assign generic_file_read directly to
their read file operation slot.

> create a new buffer and send it to the
> generic_file_read (or other) function. Then copy this

Just have a look in any other filesystem. Does it do anything like that?!?!

> buffer that we have sent to the generic_file_read to
> the actual buffer that we had received so that the
> call can be completed and the buffer received is
> filled.
> 
> Consider what I am doing now is
> 
> static ssize_t
> foo_read(file_t *file, char *buf, size_t count, loff_t
> *ppos)
> {
> 	...
> 	char __user local_buffer[10];	//TODO
> 	count = 10;			// setting a new count	
> 
> 	// read_XXX below is to be taken as a function that 
> 	// will do read for us e.g. generic_file_read can be 
> 	// such a function
> 	err = read_XXX( file, local_buffer, count, ppos);
> 
> 	// now copy local_buffer into buf 
> 	...
> 
> 	// the err is -14 or BAD ADDRESS
> 	return err;
> }
> 
> Any help regrading this is welcome.
> 
> Thanks,
> Uzair Lakhani,
> Karachi, Pakistan.
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]