linux.git/drivers/net/tun.c, branch v2.6.31

tun: Extend RTNL lock coverage over whole ioctl

2009-08-10T04:45:35+00:00

As it is, parts of the ioctl runs under the RTNL and parts of
it do not.  The unlocked section is still protected by the BKL,
but there can be subtle races.  For example, Eric Biederman and
Paul Moore observed that if two threads tried to create two tun
devices on the same file descriptor, then unexpected results
may occur.

As there isn't anything in the ioctl that is expected to sleep
indefinitely, we can prevent this from occurring by extending
the RTNL lock coverage.

This also allows to get rid of the BKL.

Finally, I changed tun_get_iff to take a tun device in order to
avoid calling tun_put which would dead-lock as it also tries to
take the RTNL lock.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller

tun/tap: Fix crashes if open() /dev/net/tun and then poll() it.

2009-07-06T19:47:07+00:00

Fix NULL pointer dereference in tun_chr_pool() introduced by commit
33dccbb050bbe35b88ca8cf1228dcf3e4d4b3554 ("tun: Limit amount of queued
packets per device") and triggered by this code:

	int fd;
	struct pollfd pfd;
	fd = open("/dev/net/tun", O_RDWR);
	pfd.fd = fd;
	pfd.events = POLLIN | POLLOUT;
	poll(&pfd, 1, 0);

Reported-by: Eugene Kapun 
Signed-off-by: Mariusz Kozlowski 
Signed-off-by: David S. Miller

tun: Fix device unregister race

2009-07-06T01:03:18+00:00

It is currently possible for an asynchronous device unregister
to cause the same tun device to be unregistered twice.  This
is because the unregister in tun_chr_close only checks whether
__tun_get(tfile) != NULL.  This however has nothing to do with
whether the device has already been unregistered.  All it tells
you is whether __tun_detach has been called.

This patch fixes this by using the most obvious thing to test
whether the device has been unregistered.

It also moves __tun_detach outside of rtnl_unlock since nothing
that it does requires that lock.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller

Driver Core: misc: add nodename support for misc devices.

2009-06-16T04:30:25+00:00

This adds support for misc devices to report their requested nodename to
userspace.  It also updates a number of misc drivers to provide the
needed subdirectory and device name to be used for them.

Signed-off-by: Kay Sievers 
Signed-off-by: Jan Blunck 
Signed-off-by: Greg Kroah-Hartman

tun: Fix unregister race

2009-06-08T07:44:31+00:00

It is possible for tun_chr_close to race with dellink on the
a tun device.  In which case if __tun_get runs before dellink
but dellink runs before tun_chr_close calls unregister_netdevice
we will attempt to unregister the netdevice after it is already
gone.  

The two cases are already serialized on the rtnl_lock, so I have
gone for the cheap simple fix of moving rtnl_lock to cover __tun_get
in tun_chr_close.  Eliminating the possibility of the tun device
being unregistered between __tun_get and unregister_netdevice in
tun_chr_close.

Signed-off-by: Eric W. Biederman 
Tested-by: David Woodhouse 
Signed-off-by: David S. Miller

tun: Fix copy/paste error in tun_get_user

2009-06-08T07:27:28+00:00

Use the right structure while incrementing the offset in tun_get_user.

Signed-off-by: Sridhar Samudrala 
Acked-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller

tun: Optimise handling of bogus gso->hdr_len

2009-06-08T07:20:01+00:00

As all current versions of virtio_net generate a value for the
header length that's too small, we should optimise this so that
we don't copy it twice.  This can be done by ensuring that it is
at least as large as the place where we'll write the checksum.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller

tun: Only wake up writers

2009-06-04T04:45:55+00:00

When I added socket accounting to tun I inadvertently introduced
spurious wake-up events that kills qemu performance.  The problem
occurs when qemu polls on the tun fd for read, and then transmits
packets.  For each packet transmitted, we will wake up qemu even
if it only cares about read events.

Now this affects all sockets, but it is only a new problem for
tun.  So this patch tries to fix it for tun first and we can then
look at the problem in general.
 
Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller

tun: add tun_flags, owner, group attributes in sysfs

2009-05-10T05:54:21+00:00

This patch adds three attribute files in /sys/class/net/$dev/ for tun
devices; allowing userspace to obtain the information which TUNGETIFF
offers, and more, but without having to attach to the device in question
(which may not be possible if it's in use).

It also fixes a bug which has been present in the TUNGETIFF ioctl since
its inception, where it would never set IFF_TUN or IFF_TAP according to
the device type. (Look carefully at the code which I remove from
tun_get_iff() and how the new tun_flags() helper is subtly different).

Signed-off-by: David Woodhouse 
Signed-off-by: David S. Miller

tun: add IFF_TUN_EXCL flag to avoid opening a persistent device.

2009-04-27T10:23:54+00:00

When creating a certain types of VPN, NetworkManager will first attempt
to find an available tun device by iterating through 'vpn%d' until it
finds one that isn't already busy. Then it'll set that to be persistent
and owned by the otherwise unprivileged user that the VPN dæmon itself
runs as.

There's a race condition here -- during the period where the vpn%d
device is created and we're waiting for the VPN dæmon to actually
connect and use it, if we try to create _another_ device we could end up
re-using the same one -- because trying to open it again doesn't get
-EBUSY as it would while it's _actually_ busy.

So solve this, we add an IFF_TUN_EXCL flag which causes tun_set_iff() to
fail if it would be opening an existing persistent tundevice -- so that
we can make sure we're getting an entirely _new_ device.

Signed-off-by: David Woodhouse 
Signed-off-by: David S. Miller