From: Max Krasnyansky <maxk@qualcomm.com>
To: David Miller <davem@davemloft.net>
Cc: <mikulas@artax.karlin.mff.cuni.cz>, <eric.dumazet@gmail.com>,
<netdev@vger.kernel.org>
Subject: Re: [PATCH] Crash in tun
Date: Thu, 19 Jul 2012 10:57:12 -0700 [thread overview]
Message-ID: <50084A78.6060602@qualcomm.com> (raw)
In-Reply-To: <20120719.104721.1649022907880598997.davem@davemloft.net>
On 07/19/2012 10:47 AM, David Miller wrote:
> From: Max Krasnyansky <maxk@qualcomm.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@gondor.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
next prev parent reply other threads:[~2012-07-19 17:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-19 1:12 [PATCH] Crash in tun Mikulas Patocka
2012-07-19 6:09 ` Eric Dumazet
2012-07-19 15:28 ` David Miller
2012-07-19 16:13 ` Mikulas Patocka
2012-07-19 17:44 ` Max Krasnyansky
2012-07-19 17:47 ` David Miller
2012-07-19 17:57 ` Max Krasnyansky [this message]
2012-07-20 18:23 ` David Miller
2012-07-21 7:55 ` Al Viro
2012-07-21 7:55 ` Al Viro
2012-07-21 9:53 ` Nicholas A. Bellinger
2012-07-21 9:53 ` Nicholas A. Bellinger
2012-07-23 9:43 ` David Laight
2012-07-23 9:43 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50084A78.6060602@qualcomm.com \
--to=maxk@qualcomm.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=mikulas@artax.karlin.mff.cuni.cz \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.