On Wed, 29 Jul 2009, Randall Stewart wrote:
Instead of using additional argument to the sctp_add_to_readq() function,
wouldn't it be sufficient to just check with mtx_owned(9) if the lock is
already held?
Hmm... I suppose one could go that way... but traditionally upper code as
told the
Author: rrs
Date: Tue Jul 28 14:09:06 2009
New Revision: 195918
URL: http://svn.freebsd.org/changeset/base/195918
Log:
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
On Tue, Jul 28, 2009 at 02:09:07PM +, Randall Stewart wrote:
Author: rrs
Date: Tue Jul 28 14:09:06 2009
New Revision: 195918
URL: http://svn.freebsd.org/changeset/base/195918
Log:
Turns out that when a receiver forwards through its TNS's the
processing code holds the read lock
On Jul 29, 2009, at 1:10 AM, Pawel Jakub Dawidek wrote:
On Tue, Jul 28, 2009 at 02:09:07PM +, Randall Stewart wrote:
Author: rrs
Date: Tue Jul 28 14:09:06 2009
New Revision: 195918
URL: http://svn.freebsd.org/changeset/base/195918
Log:
Turns out that when a receiver forwards through its
On Wed, Jul 29, 2009 at 01:23:24AM -0400, Randall Stewart wrote:
Instead of using additional argument to the sctp_add_to_readq()
function, wouldn't it be sufficient to just check with mtx_owned(9) if
the lock is already held?
Hmm... I suppose one could go that way... but traditionally upper
