[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070126131808.GE1639@ff.dom.local>
Date: Fri, 26 Jan 2007 14:18:08 +0100
From: Jarek Poplawski <jarkao2@...pl>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Masayuki Nakagawa <nakagawa.msy@...s.nec.co.jp>,
davem@...emloft.net, yoshfuji@...ux-ipv6.org, mhuth@...sta.com,
netdev@...r.kernel.org, Alexey Kuznetsov <kuznet@....inr.ac.ru>
Subject: Re: [PATCH] TCP: Replace __kfree_skb() with kfree_skb()
On Fri, Jan 26, 2007 at 12:02:35PM +0100, Jarek Poplawski wrote:
> On Fri, Jan 26, 2007 at 09:45:18PM +1100, Herbert Xu wrote:
> > On Fri, Jan 26, 2007 at 11:18:38AM +0100, Jarek Poplawski wrote:
> > >
> > > I don't mean it's necessary. I mean now skb is freed
> > > unconditionally and after this patch, if there is some
> > > error in counting, skb will stay. I thought Masayuki
> > > wrote about such possibility, but if I missed his
> > > point, then the rest is really O.K.
> >
> > OK, I see what you mean.
> >
> > I'm not aware of anybody who has coded in this way. Alexey & Dave,
> > do you know of any place where __kfree_skb is used to free an skb
> > whose ref count is greater than 1?
>
> I'm sure it wasn't done on purpose! But it could hide
> some errors anyway.
But not sure anymore...
I've only now read the original thread of this problem
and this long note about security. I need more time to
understand this, but now I'm not sure Masayuki's server
isn't doing something against the policy of this note
(at the first sight it looks like this kind of skb
isn't welcommed there).
So maybe I miss something, but there could be also
possibility this __kfree_skb prevents some errors in
a hard way - I'm not sure: on purpose or accidentally.
Have a lot of fun in the weekend,
Jarek P.
-
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