<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/sys/netgraph/bluetooth/socket/ng_btsocket_rfcomm.c, branch release/6.0.0_cvs</title>
<subtitle>FreeBSD source tree</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/'/>
<entry>
<title>This commit was manufactured by cvs2svn to create tag</title>
<updated>2005-11-03T00:35:26+00:00</updated>
<author>
<name>cvs2svn</name>
<email>cvs2svn@FreeBSD.org</email>
</author>
<published>2005-11-03T00:35:26+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=3640cb54210edbb7edbf1b12ef0127ecfcea967d'/>
<id>3640cb54210edbb7edbf1b12ef0127ecfcea967d</id>
<content type='text'>
'RELENG_6_0_0_RELEASE'.

This commit was manufactured to restore the state of the 6.0-RELEASE image.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
'RELENG_6_0_0_RELEASE'.

This commit was manufactured to restore the state of the 6.0-RELEASE image.
</pre>
</div>
</content>
</entry>
<entry>
<title>In ng_btsocket_rfcomm_receive_frame() correctly set length variable when</title>
<updated>2005-04-06T18:55:58+00:00</updated>
<author>
<name>Maksim Yevmenkin</name>
<email>emax@FreeBSD.org</email>
</author>
<published>2005-04-06T18:55:58+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=f93b258c9485da1fa12cf249a74795c2e7fdbf8a'/>
<id>f93b258c9485da1fa12cf249a74795c2e7fdbf8a</id>
<content type='text'>
EA bit is set in hdr-&gt;length (16-bit length). This currently has no effect
on the rest of the code. It just fixes the debug message.

MFC After:	3 weeks
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
EA bit is set in hdr-&gt;length (16-bit length). This currently has no effect
on the rest of the code. It just fixes the debug message.

MFC After:	3 weeks
</pre>
</div>
</content>
</entry>
<entry>
<title>move ptr use down to after null check</title>
<updated>2005-02-26T02:31:34+00:00</updated>
<author>
<name>Sam Leffler</name>
<email>sam@FreeBSD.org</email>
</author>
<published>2005-02-26T02:31:34+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=81c95c5292455d87492832ae194cc83df0e55ca3'/>
<id>81c95c5292455d87492832ae194cc83df0e55ca3</id>
<content type='text'>
Noticed by:	Coverity Prevent analysis tool
Reviewed by:	emax
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Noticed by:	Coverity Prevent analysis tool
Reviewed by:	emax
</pre>
</div>
</content>
</entry>
<entry>
<title>In the current world order, solisten() implements the state transition of</title>
<updated>2005-02-21T21:58:17+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2005-02-21T21:58:17+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=0daccb9c9439393cb1c83104717ab7e0e4db26b0'/>
<id>0daccb9c9439393cb1c83104717ab7e0e4db26b0</id>
<content type='text'>
a socket from a regular socket to a listening socket able to accept new
connections.  As part of this state transition, solisten() calls into the
protocol to update protocol-layer state.  There were several bugs in this
implementation that could result in a race wherein a TCP SYN received
in the interval between the protocol state transition and the shortly
following socket layer transition would result in a panic in the TCP code,
as the socket would be in the TCPS_LISTEN state, but the socket would not
have the SO_ACCEPTCONN flag set.

This change does the following:

- Pushes the socket state transition from the socket layer solisten() to
  to socket "library" routines called from the protocol.  This permits
  the socket routines to be called while holding the protocol mutexes,
  preventing a race exposing the incomplete socket state transition to TCP
  after the TCP state transition has completed.  The check for a socket
  layer state transition is performed by solisten_proto_check(), and the
  actual transition is performed by solisten_proto().

- Holds the socket lock for the duration of the socket state test and set,
  and over the protocol layer state transition, which is now possible as
  the socket lock is acquired by the protocol layer, rather than vice
  versa.  This prevents additional state related races in the socket
  layer.

This permits the dual transition of socket layer and protocol layer state
to occur while holding locks for both layers, making the two changes
atomic with respect to one another.  Similar changes are likely require
elsewhere in the socket/protocol code.

Reported by:		Peter Holm &lt;peter@holm.cc&gt;
Review and fixes from:	emax, Antoine Brodin &lt;antoine.brodin@laposte.net&gt;
Philosophical head nod:	gnn
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
a socket from a regular socket to a listening socket able to accept new
connections.  As part of this state transition, solisten() calls into the
protocol to update protocol-layer state.  There were several bugs in this
implementation that could result in a race wherein a TCP SYN received
in the interval between the protocol state transition and the shortly
following socket layer transition would result in a panic in the TCP code,
as the socket would be in the TCPS_LISTEN state, but the socket would not
have the SO_ACCEPTCONN flag set.

This change does the following:

- Pushes the socket state transition from the socket layer solisten() to
  to socket "library" routines called from the protocol.  This permits
  the socket routines to be called while holding the protocol mutexes,
  preventing a race exposing the incomplete socket state transition to TCP
  after the TCP state transition has completed.  The check for a socket
  layer state transition is performed by solisten_proto_check(), and the
  actual transition is performed by solisten_proto().

- Holds the socket lock for the duration of the socket state test and set,
  and over the protocol layer state transition, which is now possible as
  the socket lock is acquired by the protocol layer, rather than vice
  versa.  This prevents additional state related races in the socket
  layer.

This permits the dual transition of socket layer and protocol layer state
to occur while holding locks for both layers, making the two changes
atomic with respect to one another.  Similar changes are likely require
elsewhere in the socket/protocol code.

Reported by:		Peter Holm &lt;peter@holm.cc&gt;
Review and fixes from:	emax, Antoine Brodin &lt;antoine.brodin@laposte.net&gt;
Philosophical head nod:	gnn
</pre>
</div>
</content>
</entry>
<entry>
<title>/* -&gt; /*- for license, minor formatting changes</title>
<updated>2005-01-07T01:45:51+00:00</updated>
<author>
<name>Warner Losh</name>
<email>imp@FreeBSD.org</email>
</author>
<published>2005-01-07T01:45:51+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=c398230b64aea809cb7c5cea8db580af7097920c'/>
<id>c398230b64aea809cb7c5cea8db580af7097920c</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Push acquisition of the accept mutex out of sofree() into the caller</title>
<updated>2004-10-18T22:19:43+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2004-10-18T22:19:43+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=81158452be7803fda8aa36feb4464d5301dce85c'/>
<id>81158452be7803fda8aa36feb4464d5301dce85c</id>
<content type='text'>
(sorele()/sotryfree()):

- This permits the caller to acquire the accept mutex before the socket
  mutex, avoiding sofree() having to drop the socket mutex and re-order,
  which could lead to races permitting more than one thread to enter
  sofree() after a socket is ready to be free'd.

- This also covers clearing of the so_pcb weak socket reference from
  the protocol to the socket, preventing races in clearing and
  evaluation of the reference such that sofree() might be called more
  than once on the same socket.

This appears to close a race I was able to easily trigger by repeatedly
opening and resetting TCP connections to a host, in which the
tcp_close() code called as a result of the RST raced with the close()
of the accepted socket in the user process resulting in simultaneous
attempts to de-allocate the same socket.  The new locking increases
the overhead for operations that may potentially free the socket, so we
will want to revise the synchronization strategy here as we normalize
the reference counting model for sockets.  The use of the accept mutex
in freeing of sockets that are not listen sockets is primarily
motivated by the potential need to remove the socket from the
incomplete connection queue on its parent (listen) socket, so cleaning
up the reference model here may allow us to substantially weaken the
synchronization requirements.

RELENG_5_3 candidate.

MFC after:	3 days
Reviewed by:	dwhite
Discussed with:	gnn, dwhite, green
Reported by:	Marc UBM Bocklet &lt;ubm at u-boot-man dot de&gt;
Reported by:	Vlad &lt;marchenko at gmail dot com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
(sorele()/sotryfree()):

- This permits the caller to acquire the accept mutex before the socket
  mutex, avoiding sofree() having to drop the socket mutex and re-order,
  which could lead to races permitting more than one thread to enter
  sofree() after a socket is ready to be free'd.

- This also covers clearing of the so_pcb weak socket reference from
  the protocol to the socket, preventing races in clearing and
  evaluation of the reference such that sofree() might be called more
  than once on the same socket.

This appears to close a race I was able to easily trigger by repeatedly
opening and resetting TCP connections to a host, in which the
tcp_close() code called as a result of the RST raced with the close()
of the accepted socket in the user process resulting in simultaneous
attempts to de-allocate the same socket.  The new locking increases
the overhead for operations that may potentially free the socket, so we
will want to revise the synchronization strategy here as we normalize
the reference counting model for sockets.  The use of the accept mutex
in freeing of sockets that are not listen sockets is primarily
motivated by the potential need to remove the socket from the
incomplete connection queue on its parent (listen) socket, so cleaning
up the reference model here may allow us to substantially weaken the
synchronization requirements.

RELENG_5_3 candidate.

MFC after:	3 days
Reviewed by:	dwhite
Discussed with:	gnn, dwhite, green
Reported by:	Marc UBM Bocklet &lt;ubm at u-boot-man dot de&gt;
Reported by:	Vlad &lt;marchenko at gmail dot com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Correct merge-o: make sure to unlock symmetrically socket buffer</title>
<updated>2004-06-18T05:09:42+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2004-06-18T05:09:42+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=68548aa4c6fb3f51053217c682ca8e93237c4ad8'/>
<id>68548aa4c6fb3f51053217c682ca8e93237c4ad8</id>
<content type='text'>
locks on bluetooth sockets when clearing upcall flags.

Submitted by:	emax
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
locks on bluetooth sockets when clearing upcall flags.

Submitted by:	emax
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge additional socket buffer locking from rwatson_netperf:</title>
<updated>2004-06-17T22:48:11+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2004-06-17T22:48:11+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=9535efc00de36129762534223a2f5782cc5fe472'/>
<id>9535efc00de36129762534223a2f5782cc5fe472</id>
<content type='text'>
- Lock down low hanging fruit use of sb_flags with socket buffer
  lock.

- Lock down low hanging fruit use of so_state with socket lock.

- Lock down low hanging fruit use of so_options.

- Lock down low-hanging fruit use of sb_lowwat and sb_hiwat with
  socket buffer lock.

- Annotate situations in which we unlock the socket lock and then
  grab the receive socket buffer lock, which are currently actually
  the same lock.  Depending on how we want to play our cards, we
  may want to coallesce these lock uses to reduce overhead.

- Convert a if()-&gt;panic() into a KASSERT relating to so_state in
  soaccept().

- Remove a number of splnet()/splx() references.

More complex merging of socket and socket buffer locking to
follow.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
- Lock down low hanging fruit use of sb_flags with socket buffer
  lock.

- Lock down low hanging fruit use of so_state with socket lock.

- Lock down low hanging fruit use of so_options.

- Lock down low-hanging fruit use of sb_lowwat and sb_hiwat with
  socket buffer lock.

- Annotate situations in which we unlock the socket lock and then
  grab the receive socket buffer lock, which are currently actually
  the same lock.  Depending on how we want to play our cards, we
  may want to coallesce these lock uses to reduce overhead.

- Convert a if()-&gt;panic() into a KASSERT relating to so_state in
  soaccept().

- Remove a number of splnet()/splx() references.

More complex merging of socket and socket buffer locking to
follow.
</pre>
</div>
</content>
</entry>
<entry>
<title>The socket field so_state is used to hold a variety of socket related</title>
<updated>2004-06-14T18:16:22+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2004-06-14T18:16:22+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=c0b99ffa021c0be74d6ab90a6eccfe511be8bb19'/>
<id>c0b99ffa021c0be74d6ab90a6eccfe511be8bb19</id>
<content type='text'>
flags relating to several aspects of socket functionality.  This change
breaks out several bits relating to send and receive operation into a
new per-socket buffer field, sb_state, in order to facilitate locking.
This is required because, in order to provide more granular locking of
sockets, different state fields have different locking properties.  The
following fields are moved to sb_state:

  SS_CANTRCVMORE            (so_state)
  SS_CANTSENDMORE           (so_state)
  SS_RCVATMARK              (so_state)

Rename respectively to:

  SBS_CANTRCVMORE           (so_rcv.sb_state)
  SBS_CANTSENDMORE          (so_snd.sb_state)
  SBS_RCVATMARK             (so_rcv.sb_state)

This facilitates locking by isolating fields to be located with other
identically locked fields, and permits greater granularity in socket
locking by avoiding storing fields with different locking semantics in
the same short (avoiding locking conflicts).  In the future, we may
wish to coallesce sb_state and sb_flags; for the time being I leave
them separate and there is no additional memory overhead due to the
packing/alignment of shorts in the socket buffer structure.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
flags relating to several aspects of socket functionality.  This change
breaks out several bits relating to send and receive operation into a
new per-socket buffer field, sb_state, in order to facilitate locking.
This is required because, in order to provide more granular locking of
sockets, different state fields have different locking properties.  The
following fields are moved to sb_state:

  SS_CANTRCVMORE            (so_state)
  SS_CANTSENDMORE           (so_state)
  SS_RCVATMARK              (so_state)

Rename respectively to:

  SBS_CANTRCVMORE           (so_rcv.sb_state)
  SBS_CANTSENDMORE          (so_snd.sb_state)
  SBS_RCVATMARK             (so_rcv.sb_state)

This facilitates locking by isolating fields to be located with other
identically locked fields, and permits greater granularity in socket
locking by avoiding storing fields with different locking semantics in
the same short (avoiding locking conflicts).  In the future, we may
wish to coallesce sb_state and sb_flags; for the time being I leave
them separate and there is no additional memory overhead due to the
packing/alignment of shorts in the socket buffer structure.
</pre>
</div>
</content>
</entry>
<entry>
<title>Extend coverage of SOCK_LOCK(so) to include so_count, the socket</title>
<updated>2004-06-12T20:47:32+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2004-06-12T20:47:32+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=395a08c90416e029c757cb51721b87b83fd0194b'/>
<id>395a08c90416e029c757cb51721b87b83fd0194b</id>
<content type='text'>
reference count:

- Assert SOCK_LOCK(so) macros that directly manipulate so_count:
  soref(), sorele().

- Assert SOCK_LOCK(so) in macros/functions that rely on the state of
  so_count: sofree(), sotryfree().

- Acquire SOCK_LOCK(so) before calling these functions or macros in
  various contexts in the stack, both at the socket and protocol
  layers.

- In some cases, perform soisdisconnected() before sotryfree(), as
  this could result in frobbing of a non-present socket if
  sotryfree() actually frees the socket.

- Note that sofree()/sotryfree() will release the socket lock even if
  they don't free the socket.

Submitted by:	sam
Sponsored by:	FreeBSD Foundation
Obtained from:	BSD/OS
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
reference count:

- Assert SOCK_LOCK(so) macros that directly manipulate so_count:
  soref(), sorele().

- Assert SOCK_LOCK(so) in macros/functions that rely on the state of
  so_count: sofree(), sotryfree().

- Acquire SOCK_LOCK(so) before calling these functions or macros in
  various contexts in the stack, both at the socket and protocol
  layers.

- In some cases, perform soisdisconnected() before sotryfree(), as
  this could result in frobbing of a non-present socket if
  sotryfree() actually frees the socket.

- Note that sofree()/sotryfree() will release the socket lock even if
  they don't free the socket.

Submitted by:	sam
Sponsored by:	FreeBSD Foundation
Obtained from:	BSD/OS
</pre>
</div>
</content>
</entry>
</feed>
