Date: Tue, 28 Jul 2009 14:09:06 +0000 (UTC) From: Randall Stewart <rrs@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/netinet sctp_auth.c sctp_indata.c sctputil.c sctputil.h Message-ID: <200907281409.n6SE9T5A081302@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
rrs 2009-07-28 14:09:06 UTC
FreeBSD src repository
Modified files:
sys/netinet sctp_auth.c sctp_indata.c sctputil.c
sctputil.h
Log:
SVN rev 195918 on 2009-07-28 14:09:06Z by rrs
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
Revision Changes Path
1.23 +1 -1 src/sys/netinet/sctp_auth.c
1.64 +15 -9 src/sys/netinet/sctp_indata.c
1.93 +21 -12 src/sys/netinet/sctputil.c
1.37 +3 -0 src/sys/netinet/sctputil.h
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907281409.n6SE9T5A081302>