[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50084A78.6060602@qualcomm.com>
Date: Thu, 19 Jul 2012 10:57:12 -0700
From: Max Krasnyansky <maxk@...lcomm.com>
To: David Miller <davem@...emloft.net>
CC: <mikulas@...ax.karlin.mff.cuni.cz>, <eric.dumazet@...il.com>,
<netdev@...r.kernel.org>
Subject: Re: [PATCH] Crash in tun
On 07/19/2012 10:47 AM, David Miller wrote:
> From: Max Krasnyansky <maxk@...lcomm.com>
> Date: Thu, 19 Jul 2012 10:44:01 -0700
>
>> btw I don't remember now who added the socket business to tun_struct and why.
>
> Is GIT really so broken on your computer that you can't find the
> answer to this question in like 5 seconds as I just did?
No. I'm just too lazy these days. Too much surfing I guess :).
> commit 33dccbb050bbe35b88ca8cf1228dcf3e4d4b3554
> Author: Herbert Xu <herbert@...dor.apana.org.au>
> Date: Thu Feb 5 21:25:32 2009 -0800
>
> tun: Limit amount of queued packets per device
> <snip>
> This patch attempts to apply the same bandaid to the tuntap device.
> It creates a pseudo-socket object which is used to account our
> packets just as a normal socket does for UDP. Of course things
> are a little complex because we're actually reinjecting traffic
> back into the stack rather than out of the stack.
Thanks for the info. Overall it definitely makes sense. Still feels a bit of an overkill.
i.e. That we need to allocated a socket just for accounting but I guess all the involved
skb primitives are heavily based on that. If there are other use cases like this maybe
it makes sense to factor accounting stuff out of the socket struct?
Max
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists