[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20070315.180834.39171823.davem@davemloft.net>
Date: Thu, 15 Mar 2007 18:08:34 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: dev@...ru
Cc: devel@...nvz.org, adobriyan@...ru, netdev@...r.kernel.org
Subject: Re: [Devel] Re: [PATCH] Copy mac_len in skb_clone() as well
From: Kirill Korotaev <dev@...ru>
Date: Thu, 15 Mar 2007 13:33:12 +0300
> David Miller wrote:
> > From: Alexey Dobriyan <adobriyan@...ru>
> > Date: Wed, 14 Mar 2007 16:07:11 +0300
> >
> >
> >>ANK says: "It is rarely used, that's wy it was not noticed.
> >>But in the places, where it is used, it should be disaster."
> >>
> >>Signed-off-by: Alexey Dobriyan <adobriyan@...ru>
> >
> >
> > Applied.
> >
> > What bug triggered that helped you discover this? Or is it
> > merely from a code audit?
> Ohhh, it is a fairy-tale to tell the truth :)
> We had some unexplainable problems with java application in OpenVZ kernel.
> It didn't work sometimes, but worked fine (!) with CONFIG_SLAB_DEBUG.
> Alexey blamed java :), but ...
> Then we found that poising one of the bits in slab cache was curing it.
> After that we found that the problem is related to fclone cache.
> And then we found that not all the fields are initialized during cloning.
> The bug was related to our own skb->field we introduced,
> but we analyzed the code and found this as well.
Thanks for the detailed information.
-
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