Date: Sat, 12 Sep 2009 19:01:41 GMT From: bms@FreeBSD.org To: stef@memberwebs.com, bms@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/138689: [netinet] patch] Multicast: IP_DROP_MEMBERSHIP should return EADDRNOTAVAIL for invalid address Message-ID: <200909121901.n8CJ1fEG039523@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
Synopsis: [netinet] patch] Multicast: IP_DROP_MEMBERSHIP should return EADDRNOTAVAIL for invalid address State-Changed-From-To: open->patched State-Changed-By: bms State-Changed-When: Sat 12 Sep 2009 19:00:58 UTC State-Changed-Why: Committed to HEAD as rev 197129.· Thanks for your work in tracking down and fixing this issue. This fix deals with the POLA violation in the userland API, but doesn't fix the underlying issue, which requires a bit more thought. The inpcb layer will not learn about interfaces going down, even though the netinet stack cleans up its references to link-layer structures. To be frank: this situation comes about largely because getting the BSD network stack right for hot-swappable interfaces, requires swinging a big hammer around in a number of APIs and structures. In short, it's the sort of thing which gets chewed over at developer summits. ;-) IPv4 multicast structures are keyed by ifp. Should ifp be invalidated due to an interface being detached at runtime, and a userland consumer later tries to delete a membership, the lookup will fail. The membership will however still exist. There isn't really an easy way to deal with this, without implementing a full walk of all socket(s) with memberships on the ifp, and invalidating the inpcb's reference to the group, when in_ifdetach() is actually called on interface detach. The membership is eventually cleaned up by the call to inp_freemoptions() during the PCB cleanup when the socket is closed. It is a non-trivial issue to resolve, because it would involve taking socket-layer locks from a lower level path, leading to a lock order violation. Coding around issues in the stack is not really the right approach-- the better approach is to fix problems at source. Unfortunately, the project(s) involved are all separate, and communication hasn't really been that great between them in the past. That, and it takes a while for fixes to percolate into kernels because of release schedules. The code in Quagga looks really ugly, but I suppose this is what ends up happening in situations like this, where the development of stack components is not that cohesive. http://www.freebsd.org/cgi/query-pr.cgi?pr=138689
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200909121901.n8CJ1fEG039523>