From owner-freebsd-net@FreeBSD.ORG Mon Apr 7 09:40:11 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29E67B82 for ; Mon, 7 Apr 2014 09:40:11 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D901B20A for ; Mon, 7 Apr 2014 09:40:10 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WX5nY-0002dr-9N for freebsd-net@freebsd.org; Mon, 07 Apr 2014 11:25:00 +0200 Received: from 217.30.88.7 ([217.30.88.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Apr 2014 11:25:00 +0200 Received: from jcharbon by 217.30.88.7 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Apr 2014 11:25:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Julien Charbon Subject: Re: panic in -HEAD multicast code Date: Mon, 07 Apr 2014 11:24:54 +0200 Lines: 38 Message-ID: <53426EE6.5020409@verisign.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 217.30.88.7 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 09:40:11 -0000 Hi Adrian, On 07/04/14 04:58, Adrian Chadd wrote: > I'm seeing a panic in the multicast code path. I reproduce this by > trying to browse network sharing on VLC. > > The panic: > > http://people.freebsd.org/~adrian/ath/core.txt.0 > > Any ideas? We believe this issue is due to a race condition in multicast code. We found it tracking down another unrelated bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=185043 See provided details on this race condition in PR description section starting with: "With even this patch in place, we have further found a subsequent race condition that...". In short, it looks like a race between a thread setting/allocating a new multicast address on an interface and calling: inp_setmoptions() -> inp_join_group() -> inp_join_group_locked() -> in_getmulti() and a thread detaching this interface, purging all associated multicast addresses and calling: if_detach() -> if_detach_internal() -> if_purgemaddrs() -> if_delmulti_locked() -> if_freemulti() However, we did not find a way to fix it without unwanted side effects and we asked for comments/ideas. -- Julien