Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 08 Sep 2009 16:11:23 +0100
From:      Bruce Simpson <bms@incunabulum.net>
To:        Shteryana Shopova <shteryana@gmail.com>
Cc:        "freebsd-net@FreeBSD.org" <freebsd-net@freebsd.org>, stef@memberwebs.com
Subject:   Re: Panic in imo_match_source (netinet/in_mcast.c)
Message-ID:  <4AA6741B.9020403@incunabulum.net>
In-Reply-To: <61b573980909080654x50670168x39001267ad81c6a3@mail.gmail.com>
References:  <4AA65663.8050106@incunabulum.net> <4AA65861.8@incunabulum.net> <61b573980909080654x50670168x39001267ad81c6a3@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Shteryana Shopova wrote:
> Hi,
>
> I actually managed to get the same kernel dump using the following
> sample code - http://people.freebsd.org/~syrinx/mcast/mcast_crash.c
> and the crash is 100% reproducable. A temporary fix is here -
> http://people.freebsd.org/~syrinx/mcast/in_mcast.c-20090908-01.diff
> but I actually prefer that we go over the logic in inp_join_group()
> again before proposing a patch for head as this is the second assert
> panic I am seeing it causes in the last few days. I can try making up
> a proper fix if Bruce is busy, but it will take a day or two until I'm
> able to fully test it.
>   

Good catch. Yes, IP_ADD_MEMBERSHIP on an existing exclusive mode group 
with filters is an error. The comment calls it out, but you are right, a 
normal case could hit the KASSERT.

The code in the start of inp_join_group() handles all join requests, by 
mapping 3 possible sets of inbound ioctls onto 1, to make the ioctl 
processing code smaller.

So I could rephrase the fix to: explicitly check for ssa->ss.ss_family 
being AF_UNSPEC before trying to perform a search with ssa as the key, 
as this will be set by the code above.  Or commit your fix, which is a 
bit more explicit.

The assertion in imo_match_source() existed to catch v4/v6 operations 
being mixed in similar code paths. Originally I'd planned to keep v4 and 
v6 code together, but as time went on, it became clear that just 
branching the code for v6 was the right way to keep the code managable. 
v6 and v4 have a bunch of special conditions for address handling which 
just plain need to stay separate...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AA6741B.9020403>