diff options
| author | rrs <rrs@FreeBSD.org> | 2009-07-28 14:09:06 +0000 |
|---|---|---|
| committer | rrs <rrs@FreeBSD.org> | 2009-07-28 14:09:06 +0000 |
| commit | d0539309e63ba3dbebc5250db903d7a6bb8290b3 (patch) | |
| tree | 9e24d0becd12325b1811933aaaf8795ed1a4f1a1 /sys/netinet/sctp_auth.c | |
| parent | bf5de47722753ed785054f03efe75c8de61a0210 (diff) | |
| download | FreeBSD-src-d0539309e63ba3dbebc5250db903d7a6bb8290b3.zip FreeBSD-src-d0539309e63ba3dbebc5250db903d7a6bb8290b3.tar.gz | |
Turns out that when a receiver forwards through its TNS's the
processing code holds the read lock (when processing a
FWD-TSN for pr-sctp). If it finds stranded data that
can be given to the application, it calls sctp_add_to_readq().
The readq function also grabs this lock. So if INVAR is on
we get a double recurse on a non-recursive lock and panic.
This fix will change it so that readq() function gets a
flag to tell if the lock is held, if so then it does not
get the lock.
Approved by: re@freebsd.org (Kostik Belousov)
MFC after: 1 week
Diffstat (limited to 'sys/netinet/sctp_auth.c')
| -rw-r--r-- | sys/netinet/sctp_auth.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/sys/netinet/sctp_auth.c b/sys/netinet/sctp_auth.c index 6da97ec..a166cb4 100644 --- a/sys/netinet/sctp_auth.c +++ b/sys/netinet/sctp_auth.c @@ -1960,7 +1960,7 @@ sctp_notify_authentication(struct sctp_tcb *stcb, uint32_t indication, /* not that we need this */ control->tail_mbuf = m_notify; sctp_add_to_readq(stcb->sctp_ep, stcb, control, - &stcb->sctp_socket->so_rcv, 1, so_locked); + &stcb->sctp_socket->so_rcv, 1, SCTP_READ_LOCK_NOT_HELD, so_locked); } |
