Re: bridge/netfilter: regression in 2.6.39.1

[Alexander Holler <holler@ahsoftware.de>]

Am 03.06.2011 21:55, schrieb Eric Dumazet:
> Le vendredi 03 juin 2011 à 21:51 +0200, Alexander Holler a écrit :
>> Hello,
>>
>> Am 03.06.2011 21:34, schrieb Eric Dumazet:
>>>>
>>>> Commit 42923465fb8d025a2b5153f2e7ab1e6e1058bf00 does here what it
>>>> should prevent, it introduces NULL a dereference.
>>>>
>>>
>>> I cant find this commit in known trees. Could you give the real commit
>>> id and its title ?
>>
>> Sorry, I haven't seen that question at first. This is the real commit id
>> as found in the stable tree for 2.6.39. The title of that commit is
>> "bridge: initialize fake_rtable metrics"
>
> OK, its commit id is 33eb9873a283a2076f2b5628813d5365ca420ea9
>
> Please always use linux-2.6 tree commits, this saves a lot of time.

Sorry to have wasted your time with posting a full breakdown of the bug 
and a possible solution. I didn't know that stable trees are unknown to 
kernel developers and I did'nt know that the "upstream commit id" in 
comments of commits in the stable tree are referencing to commit ids in 
Linus tree.

Anyway, I've used the broken way of not using git send-email because I'm 
unsure if the solution I've offered is the best one. I'm lacking the 
knowledge about what cow_metrics() does, what it is used for, and what, 
if any, pre- or post-requisites are needed to use dst_cow_metrics_generic().

I can only say that my solution seems to work here, the machine comes up 
without an oops and I didn't have seen any other problems while using 
the bridge (which surely doesn't say anything, e.g. I'm not sure if my 
use of dst_cow_metrics_generic() may introduce a mem leak or similiar, 
it doesn't look so, but who knows).

Regards,

Alexander