summaryrefslogtreecommitdiffstats
path: root/sys/netgraph/bluetooth/socket
Commit message (Collapse)AuthorAgeFilesLines
* /* -> /*- for license, minor formatting changesimp2005-01-075-5/+15
|
* Move ng_socket and ng_btsocket initialization to SI_SUB_PROTO_DOMAIN as theymlaier2004-11-301-1/+2
| | | | | | | | | | | | | | | call net_add_domain(). Calling this function too early (or late) breaks assertations about the global domains list. Actually it should be forbidden to call net_add_domain() outside of SI_SUB_PROTO_DOMAIN completely as there are many places where we traverse the domains list unprotected, but for now we allow late calls (mostly to support netgraph). In order to really fix this we have to lock the domains list in all places or find another way to ensure that we can safely walk the list while another thread might be adding a new domain. Spotted by: se Reviewed by: julian, glebius PR: kern/73321 (partly)
* Initialize struct pr_userreqs in new/sparse style and fill in commonphk2004-11-081-84/+48
| | | | | | default elements in net_init_domain(). This makes it possible to grep these structures and see any bogosities.
* Push acquisition of the accept mutex out of sofree() into the callerrwatson2004-10-184-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (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 <ubm at u-boot-man dot de> Reported by: Vlad <marchenko at gmail dot com>
* Add '#include <sys/mbuf.h>' to fix the kernel build.emax2004-06-251-0/+1
|
* Correct merge-o: make sure to unlock symmetrically socket bufferrwatson2004-06-181-2/+2
| | | | | | locks on bluetooth sockets when clearing upcall flags. Submitted by: emax
* Merge additional socket buffer locking from rwatson_netperf:rwatson2004-06-171-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | - 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()->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.
* The socket field so_state is used to hold a variety of socket relatedrwatson2004-06-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Extend coverage of SOCK_LOCK(so) to include so_count, the socketrwatson2004-06-124-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Integrate accept locking from rwatson_netperf, introducing a newrwatson2004-06-021-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | global mutex, accept_mtx, which serializes access to the following fields across all sockets: so_qlen so_incqlen so_qstate so_comp so_incomp so_list so_head While providing only coarse granularity, this approach avoids lock order issues between sockets by avoiding ownership of the fields by a specific socket and its per-socket mutexes. While here, rewrite soclose(), sofree(), soaccept(), and sonewconn() to add assertions, close additional races and address lock order concerns. In particular: - Reorganize the optimistic concurrency behavior in accept1() to always allocate a file descriptor with falloc() so that if we do find a socket, we don't have to encounter the "Oh, there wasn't a socket" race that can occur if falloc() sleeps in the current code, which broke inbound accept() ordering, not to mention requiring backing out socket state changes in a way that raced with the protocol level. We may want to add a lockless read of the queue state if polling of empty queues proves to be important to optimize. - In accept1(), soref() the socket while holding the accept lock so that the socket cannot be free'd in a race with the protocol layer. Likewise in netgraph equivilents of the accept1() code. - In sonewconn(), loop waiting for the queue to be small enough to insert our new socket once we've committed to inserting it, or races can occur that cause the incomplete socket queue to overfill. In the previously implementation, it was sufficient to simply tested once since calling soabort() didn't release synchronization permitting another thread to insert a socket as we discard a previous one. - In soclose()/sofree()/et al, it is the responsibility of the caller to remove a socket from the incomplete connection queue before calling soabort(), which prevents soabort() from having to walk into the accept socket to release the socket from its queue, and avoids races when releasing the accept mutex to enter soabort(), permitting soabort() to avoid lock ordering issues with the caller. - Generally cluster accept queue related operations together throughout these functions in order to facilitate locking. Annotate new locking in socketvar.h.
* The SS_COMP and SS_INCOMP flags in the so_state field indicate whetherrwatson2004-06-011-1/+1
| | | | | | | | the socket is on an accept queue of a listen socket. This change renames the flags to SQ_COMP and SQ_INCOMP, and moves them to a new state field on the socket, so_qstate, as the locking for these flags is substantially different for the locking on the remainder of the flags in so_state.
* Switch to using C99 sparse initialisers for the type methods array.julian2004-05-293-37/+28
| | | | | | | | Should make no binary difference. Submitted by: Gleb Smirnoff <glebius@cell.sick.ru> Reviewed by: Harti Brandt <harti@freebsd.org> MFC after: 1 week
* Address few style issues pointed out by bdeemax2004-04-275-28/+28
| | | | Reviewed by: bde, ru
* Make sure RFCOMM multiplexor channel does not hang in DISCONNECTINGemax2004-04-231-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | state. Apparently it happens when both devices try to disconnect RFCOMM multiplexor channel at the same time. The scenario is as follows: - local device initiates RFCOMM connection to the remote device. This creates both RFCOMM multiplexor channel and data channel; - remote device terminates RFCOMM data channel (inactivity timeout); - local device acknowledges RFCOMM data channel termination. Because there is no more active data channels and local device has initiated connection it terminates RFCOMM multiplexor channel; - remote device does not acknowledges RFCOMM multiplexor channel termination. Instead it sends its own request to terminate RFCOMM multiplexor channel. Even though local device acknowledges RFCOMM multiplexor channel termination the remote device still keeps L2CAP connection open. Because of hanging RFCOMM multiplexor channel subsequent RFCOMM connections between local and remote devices will fail. Reported by: Johann Hugo <jhugo@icomtek.csir.co.za>
* Rename dup_sockaddr() to sodupsockaddr() for consistency with otherrwatson2004-03-014-7/+7
| | | | | | | | | | | | functions in kern_socket.c. Rename the "canwait" field to "mflags" and pass M_WAITOK and M_NOWAIT in from the caller context rather than "1" or "0". Correct mflags pass into mac_init_socket() from previous commit to not include M_ZERO. Submitted by: sam
* Replace deprecated NG_NODELEN with the new NG_NODESIZ. There is oneharti2004-01-261-1/+1
| | | | | | | problem here still to be solved: the sockaddr_hci has still a 16 byte field for the node name. The code currently does not correctly use the length field in the sockaddr to handle the address length, so node names get truncated to 15 characters when put into a sockaddr_hci.
* NULL -> 0 where appropriate.alfred2003-12-243-18/+18
|
* Introduce a MAC label reference in 'struct inpcb', which cachesrwatson2003-11-181-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | the MAC label referenced from 'struct socket' in the IPv4 and IPv6-based protocols. This permits MAC labels to be checked during network delivery operations without dereferencing inp->inp_socket to get to so->so_label, which will eventually avoid our having to grab the socket lock during delivery at the network layer. This change introduces 'struct inpcb' as a labeled object to the MAC Framework, along with the normal circus of entry points: initialization, creation from socket, destruction, as well as a delivery access control check. For most policies, the inpcb label will simply be a cache of the socket label, so a new protocol switch method is introduced, pr_sosetlabel() to notify protocols that the socket layer label has been updated so that the cache can be updated while holding appropriate locks. Most protocols implement this using pru_sosetlabel_null(), but IPv4/IPv6 protocols using inpcbs use the the worker function in_pcbsosetlabel(), which calls into the MAC Framework to perform a cache update. Biba, LOMAC, and MLS implement these entry points, as do the stub policy, and test policy. Reviewed by: sam, bms Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
* Update Bluetooth code.emax2003-10-125-12/+21
| | | | | Reviewed by: M. Warner Losh <imp@bsdimp.com>; John Hay <jhay@freebsd.org> Approved by: M. Warner Losh <imp@bsdimp.com> (mentor)
* Use the <sys/bitstring.h> rather than <bitstring.h>phk2003-06-135-5/+5
|
* Part one of undating the bluetooth code to the newest versionjulian2003-05-106-523/+4611
| | | | | Submitted by: Maksim Yevmenkin <m_evmenkin@yahoo.com> Approved by: re@
* Introduce an M_ASSERTPKTHDR() macro which performs the very common taskdes2003-04-081-4/+2
| | | | | | | of asserting that an mbuf has a packet header. Use it instead of hand- rolled versions wherever applicable. Submitted by: Hiten Pandya <hiten@unixdaemons.com>
* Introduce a new taskqueue that runs completely free of Giant, and inscottl2003-02-263-7/+7
| | | | | | | turns runs its tasks free of Giant too. It is intended that as drivers become locked down, they will move out of the old, Giant-bound taskqueue and into this new one. The old taskqueue has been renamed to taskqueue_swi_giant, and the new one keeps the name taskqueue_swi.
* Back out M_* changes, per decision of the TRB.imp2003-02-193-18/+18
| | | | Approved by: trb
* Remove M_TRYWAIT/M_WAITOK/M_WAIT. Callers should use 0.alfred2003-01-213-18/+18
| | | | Merge M_NOWAIT/M_DONTWAIT into a single flag M_NOWAIT.
* o Untangle the confusion with the malloc flags {M_WAITOK, M_NOWAIT} andbmilekic2002-12-192-3/+3
| | | | | | | | | | the mbuf allocator flags {M_TRYWAIT, M_DONTWAIT}. o Fix a bpf_compat issue where malloc() was defined to just call bpf_alloc() and pass the 'canwait' flag(s) along. It's been changed to call bpf_alloc() but pass the corresponding M_TRYWAIT or M_DONTWAIT flag (and only one of those two). Submitted by: Hiten Pandya <hiten@unixdaemons.com> (hiten->commit_count++)
* The second try a committing the bluetooth codejulian2002-11-205-0/+5532
Has been seen to work on several cards and communicating with several mobile phones to use them as modems etc. We are still talking with 3com to try get them to allow us to include the firmware for their pccard in the driver but the driver is here.. In the mean time it can be downloaded from the 3com website and loaded using the utility bt3cfw(8) (supplied) (instructions in the man page) Not yet linked to the build Submitted by: Maksim Yevmenkin <myevmenk@exodus.net> Approved by: re
OpenPOWER on IntegriCloud