From owner-freebsd-net@FreeBSD.ORG  Sun Feb  1 09:55:10 2015
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id C2E15989
 for <freebsd-net@FreeBSD.org>; Sun,  1 Feb 2015 09:55:10 +0000 (UTC)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
 [IPv6:2001:1900:2254:206a::16:76])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id AA259EBE
 for <freebsd-net@FreeBSD.org>; Sun,  1 Feb 2015 09:55:10 +0000 (UTC)
Received: from bugs.freebsd.org ([127.0.1.118])
 by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t119tA5Q070332
 for <freebsd-net@FreeBSD.org>; Sun, 1 Feb 2015 09:55:10 GMT
 (envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 197059] network locks up with IPv6 udp traffic
Date: Sun, 01 Feb 2015 09:55:10 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 10.0-STABLE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: rwatson@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: ae@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-197059-2472-56f0f2IQCr@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-197059-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-197059-2472@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Feb 2015 09:55:10 -0000

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197059

Robert Watson <rwatson@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rwatson@FreeBSD.org

--- Comment #2 from Robert Watson <rwatson@FreeBSD.org> ---
Some notes form an e-mail from myself to Andrey about this problem:

Basically, the general rule, with respect to lock order, is that the
network-stack input path can call the output path (e.g., inbound TCP segment
triggers an immediate send of a TCP ACK), but you can't directly call in the
other direction or you would violate the lock order. In this sort of situation,
the output path needs to reinject packets via the netisr, rather than directly
invoking the input path. This is how we handle, for example, routing-socket
packets triggered by send events -- they are enqueued to the netisr for
processing asynchronously, providing a context where transmit-pathj locks can
be safely acquired.

(Basically, pfctlinput() is never safe to call from the transmit path.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.