login
Header Space

 
 

Re: [PATCH RFC 1/5] vringfd syscall

Score:
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Rusty Russell <rusty@...>
Cc: <linux-kernel@...>, <netdev@...>, Max Krasnyansky <maxk@...>, <virtualization@...>
Date: Saturday, April 5, 2008 - 1:13 pm

Rusty Russell wrote:

Shouldn't this be calloc(1, vring_size(256, getpagesize()));?


I have a tough time seeing what you're demonstrating here.  Perhaps some 
comments?


Should select VIRTIO && VIRTIO_RING

<snip>


It seems unlikely that a caller could place both in_iov/out_iov on the 
stack since to do it safely, you would have to use vring.num which is 
determined by userspace.  Since you have to kmalloc() the buffers 
anyway, why not just allocate a single data structure within this 
function and return it.


When is this actually safe to use?


Oh, this is when it's safe to use.  You don't seem to be acquiring 
current->mm->mmap_sem here.  Also, this assumes the used ring fits 
within a single page which isn't true with a ring > 512 elements.

A consequence of this is that devices that interact with a ring queue 
atomically now have an additional capability: pinning an arbitrary 
amount of physical memory.

I think this means that it's no longer safe to give a tap fd to an 
unprivileged process regardless of how you're routing the traffic.

Regards,

Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH RFC 1/5] vringfd syscall, Anthony Liguori, (Sat Apr 5, 1:13 pm)
Re: [PATCH RFC 1/5] vringfd syscall, Rusty Russell, (Sat Apr 5, 11:03 pm)
speck-geostationary