Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> writes:
> On Wed, Apr 15, 2009 at 04:36:10PM +0800, Herbert Xu wrote:
>>
>> Let me whip up a patch.
>
> tun: Fix sk_sleep races when attaching/detaching
>
> As the sk_sleep wait queue actually lives in tfile, which may be
> detached from the tun device, bad things will happen when we use
> sk_sleep after detaching.
>
> Since the tun device is the persistent data structure here (when
> requested by the user), it makes much more sense to have the wait
> queue live there. There is no reason to have it in tfile at all
> since the only time we can wait is if we have a tun attached.
> In fact we already have a wait queue in tun_struct, so we might
> as well use it.
There is a GIGANTIC reason to have the wait queue on tfile.
If you open a file, and do ip link del tapN you can still
be blocked waiting in poll.
The problem is specifically free_poll_entry, where we call
remove_wait_queue and fput without calling any file methods.
So all of this happens without struct tun_file's count being
elevated. Which means tun_net_uninit can detach before we get
off of the stupid poll wait queue.
As documented in:
commit b2430de37ef0bc0799ffba7b5219d38ca417eb76
Author: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
Date: Tue Jan 20 11:03:21 2009 +0000
tun: Move read_wait into tun_file
The poll interface requires that the waitqueue exist while the struct
file is open. In the rare case when a tun device disappears before
the tun file closes we fail to provide this property, so move
read_wait.
This is safe now that tun_net_xmit is atomic with tun_detach.
Signed-off-by: Eric W. Biederman <ebiederm@xxxxxxxxxxxxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
I specifically moved the wait queue out of tun struct to avoid this
race.
I will see about getting the vfs to do something saner in my generic
revoke work. But for 2.6.30 we have to live with the nasties that
are there.
Nacked-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
Eric
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
