Messages in this thread | | | Date | Mon, 06 Jun 2011 08:57:59 +0200 | From | Alexander Holler <> | Subject | Re: bridge/netfilter: regression in 2.6.39.1 |
| |
Hello,
Am 04.06.2011 14:04, schrieb Alexander Holler:
> 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).
After having a second look at dst_cow_metrics_generic(), it seems my patch does introduce a small mem leak which occurs when the bridge will be build as a module and the module gets unloaded. Then the static struct dst_ops fake_dst_ops disappears and with that the memory allocated by dst_cow_metrics_generic() is lost. I'm not sure which of the dst*-functions should be called before the module gets unloaded. Maybe someone with a deeper knowledge of the that stuff could have a look at that. Or maybe just changing the true in the call to dst_cow_metrics_generic() in br_netfilter_rtable_init() to false instead of adding dst_cow_metrics_generic() to fake_dst_ops() is an alternative. As I said, I don't know what that metric-stuff does and what it is used for.
Regards,
Alexander
| |