linux-stable.git/drivers/net/tun.c, branch v3.12

tun: don't look at current when non-blocking

2013-10-08T19:38:35+00:00

We play with a wait queue even if socket is
non blocking. This is an obvious waste.
Besides, it will prevent calling the non blocking
variant when current is not valid.

Signed-off-by: Michael S. Tsirkin 
Acked-by: Jason Wang 
Signed-off-by: David S. Miller

tuntap: correctly handle error in tun_set_iff()

2013-09-12T21:21:42+00:00

Commit c8d68e6be1c3b242f1c598595830890b65cea64a
(tuntap: multiqueue support) only call free_netdev() on error in
tun_set_iff(). This causes several issues:

- memory of tun security were leaked
- use after free since the flow gc timer was not deleted and the tfile
  were not detached

This patch solves the above issues.

Reported-by: Wannes Rombouts 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
Acked-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller

tuntap: orphan frags before trying to set tx timestamp

2013-09-05T16:44:31+00:00

sock_tx_timestamp() will clear all zerocopy flags of skb which may lead the
frags never to be orphaned. This will break guest to guest traffic when zerocopy
is enabled. Fix this by orphaning the frags before trying to set tx time stamp.

The issue were introduced by commit eda297729171fe16bf34fe5b0419dfb69060f623
(tun: Support software transmit time stamping).

Cc: Richard Cochran 
Cc: Sergei Shtylyov 
Acked-by: Richard Cochran 
Signed-off-by: Jason Wang 
Signed-off-by: David S. Miller

tuntap: purge socket error queue on detach

2013-09-05T16:44:31+00:00

Commit eda297729171fe16bf34fe5b0419dfb69060f623
(tun: Support software transmit time stamping) will queue skbs into error queue
when tx stamping is enabled. But it forgets to purge the error queue during
detach. This patch fixes this.

Cc: Richard Cochran 
Acked-by: Richard Cochran 
Signed-off-by: Jason Wang 
Signed-off-by: David S. Miller

tun: Get skfilter layout

2013-08-21T19:21:45+00:00

The only thing we may have from tun device is the fprog, whic contains
the number of filter elements and a pointer to (user-space) memory
where the elements are. The program itself may not be available if the
device is persistent and detached.

Signed-off-by: Pavel Emelyanov 
Signed-off-by: David S. Miller

tun: Allow to skip filter on attach

2013-08-21T19:21:45+00:00

There's a small problem with sk-filters on tun devices. Consider
an application doing this sequence of steps:

fd = open("/dev/net/tun");
ioctl(fd, TUNSETIFF, { .ifr_name = "tun0" });
ioctl(fd, TUNATTACHFILTER, &my_filter);
ioctl(fd, TUNSETPERSIST, 1);
close(fd);

At that point the tun0 will remain in the system and will keep in
mind that there should be a socket filter at address '&my_filter'.

If after that we do

fd = open("/dev/net/tun");
ioctl(fd, TUNSETIFF, { .ifr_name = "tun0" });

we most likely receive the -EFAULT error, since tun_attach() would
try to connect the filter back. But (!) if we provide a filter at
address &my_filter, then tun0 will be created and the "new" filter
would be attached, but application may not know about that.

This may create certain problems to anyone using tun-s, but it's
critical problem for c/r -- if we meet a persistent tun device
with a filter in mind, we will not be able to attach to it to dump
its state (flags, owner, address, vnethdr size, etc.).

The proposal is to allow to attach to tun device (with TUNSETIFF)
w/o attaching the filter to the tun-file's socket. After this
attach app may e.g clean the device by dropping the filter, it
doesn't want to have one, or (in case of c/r) get information
about the device with tun ioctls.

Signed-off-by: Pavel Emelyanov 
Signed-off-by: David S. Miller

tun: Report whether the queue is attached or not

2013-08-21T19:21:45+00:00

Multiqueue tun devices allow to attach and detach from its queues
while keeping the interface itself set on file.

Knowing this is critical for the checkpoint part of criu project.

Signed-off-by: Pavel Emelyanov 
Signed-off-by: David S. Miller

tun: Add ability to create tun device with given index

2013-08-21T19:21:45+00:00

Tun devices cannot be created with ifidex user wants, but it's
required by checkpoint-restore project.

Long time ago such ability was implemented for rtnl_ops-based
interface for creating links (9c7dafbf net: Allow to create links
with given ifindex), but the only API for creating and managing
tuntap devices is ioctl-based and is evolving with adding new ones
(cde8b15f tuntap: add ioctl to attach or detach a file form tuntap
device).

Following that trend, here's how a new ioctl that sets the ifindex
for device, that _will_ be created by TUNSETIFF ioctl looks like.
So those who want a tuntap device with the ifindex N, should open
the tun device, call ioctl(fd, TUNSETIFINDEX, &N), then call TUNSETIFF.
If the index N is busy, then the register_netdev will find this out
and the ioctl would be failed with -EBUSY.

If setifindex is not called, then it will be generated as before.

Signed-off-by: Pavel Emelyanov 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2013-08-16T22:37:26+00:00

tun: signedness bug in tun_get_user()

2013-08-15T21:51:23+00:00

The recent fix d9bf5f1309 "tun: compare with 0 instead of total_len" is
not totally correct.  Because "len" and "sizeof()" are size_t type, that
means they are never less than zero.

Signed-off-by: Dan Carpenter 
Acked-by: Michael S. Tsirkin 
Acked-by: Neil Horman 
Signed-off-by: David S. Miller