From: Alexey Kuznetsov <[EMAIL PROTECTED]> Date: Wed, 19 Apr 2006 03:52:22 +0400
> Actually, this weird case in inet_get_route() is the only place, where > a dummy skb is used and it is needed mostly to resolve multicast routes. > In this case this fake skb really passes through all the engine, even > delivered to user space in some sense, and when the route is resolved, > the same skb is submitted to netlink socket. I remember, Dave found > something very bad about this and this even deserved a place in TODO list, > but franky speaking I did not understand what is so wrong with this trick. Problem there is via rt_fill_info(). When multicast route cannot be found by ipmr, it tries to use this netlink SKB to send out a probe. ipmr_get_route() is the trouble maker. If ipmr_cache_find() cannot find an entry, it tries to use the netlink SKB to send out an ipv4 packet, completely mangling it, via ipmr_cache_unresolved(). Even worse it may even free the skb on us, or queue it to mroute_socket. It is pure disaster, this entire code path. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
