linux-stable.git/drivers/net/tun.c, branch linux-2.6.26.y

tun: Persistent devices can get stuck in xoff state

2008-07-10T23:59:11+00:00

The scenario goes like this. App stops reading from tun/tap.
TX queue gets full and driver does netif_stop_queue().
App closes fd and TX queue gets flushed as part of the cleanup.
Next time the app opens tun/tap and starts reading from it but
the xoff state is not cleared. We're stuck.
Normally xoff state is cleared when netdev is brought up. But
in the case of persistent devices this happens only during
initial setup.

The fix is trivial. If device is already up when an app opens
it we clear xoff state and that gets things moving again.

Signed-off-by: Max Krasnyansky 
Tested-by: Christian Borntraeger 
Signed-off-by: David S. Miller

tun: Proper handling of IPv6 header in tun driver when TUN_NO_PI is set

2008-06-18T04:10:33+00:00

By default, tun.c running in TUN_TUN_DEV mode will set the protocol of
packet to IPv4 if TUN_NO_PI is set. My program failed to work when I
assumed that the driver will check the first nibble of packet,
determine IP version and set the appropriate protocol.

Signed-off-by: Ang Way Chuang 
Acked-by: Max Krasnyansky 
Signed-off-by: David S. Miller

tun: Multicast handling in tun_chr_ioctl() needs proper locking.

2008-04-24T10:44:43+00:00

Since these operations don't go through the normal
device calls, we have to ensure we synchronize with
those paths.

Noticed by Alan Cox.

Signed-off-by: David S. Miller

tun: Fix minor race in TUNSETLINK ioctl handling.

2008-04-24T02:37:58+00:00

Noticed by Alan Cox.

The IFF_UP test is a bit racey, because other entities
outside of this driver's ioctl handler can modify that
state, even though this ioctl handler runs under
lock_kernel().

Signed-off-by: David S. Miller

[TUN]: Allow to register tun devices in namespace.

2008-04-16T07:41:53+00:00

This is basically means that a net is set for a new device, but
actually also involves two more steps:

1. mark the tun device as "local", i.e. do not allow for it to
   move across namespaces.

This is done so, since tun device is most often associated to some
file (and thus to some process) and moving the device alone is not
valid while keeping the file and the process outside. The need in 
ability to move a detached persistent device is to be investigated 
later.

2. get the tun device's net when tun becomes attached and put one
   when it becomes detached.

This is needed to handle the case when a task owning the tun dies,
but a files lives for some more time - in this case we must not
allow for net to be freed, since its exit hook will spoil that file's
private data by unregistering the tun from under tun_chr_close.

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

[TUN]: Make the tun_dev_list per-net.

2008-04-16T07:41:16+00:00

Remove the static tun_dev_list and replace its occurrences in
driver with per-net one.

It is used in two places - in tun_set_iff and tun_cleanup. In 
the first case it's legal to use current net_ns. In the cleanup
call - move the loop, that unregisters all devices in net exit
hook.

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

[TUN]: Introduce the tun_net structure and init/exit net ops.

2008-04-16T07:40:46+00:00

This is the first step in making tuntap devices work in net 
namespaces. The structure mentioned is pointed by generic
net pointer with tun_net_id id, and tun driver fills one on 
its load. It will contain only the tun devices list.

So declare this structure and introduce net init and exit hooks.

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

net: check for underlength tap writes

2008-04-13T01:49:30+00:00

If the user gives a packet under 14 bytes, we'll end up reading off the end
of the skb (not oopsing, just reading off the end).

Signed-off-by: Rusty Russell 
Acked-by: Max Krasnyanskiy 
Signed-off-by: David S. Miller

net: make struct tun_struct private to tun.c

2008-04-13T01:48:58+00:00

There's no reason for this to be in the header, and it just hurts
recompile time.

Signed-off-by: Rusty Russell 
Acked-by: Max Krasnyanskiy 
Signed-off-by: David S. Miller

[TUN]: Fix RTNL-locking in tun/tap driver

2008-02-29T20:26:21+00:00

Current tun/tap driver sets also net device's hw address when asked to
change character device's hw address. This is a good idea, but it
misses RTLN-locking, resulting following error message in 2.6.25-rc3's
inetdev_event() function:

RTNL: assertion failed at net/ipv4/devinet.c (1050)

Attached patch fixes this problem.

Signed-off-by: Kim B. Heino 
Signed-off-by: David S. Miller