src-test2/sys/kern/sys_socket.c, branch release/5.5.0

Merge sys_socket.c:1.68 from HEAD to RELENG_5:

2005-04-01T15:02:12Z

The SO_NOSIGPIPE socket option allows a user process to mark a socket so that the socket does not generate SIGPIPE, only EPIPE, when a write is attempted after socket shutdown. When the option was introduced in 2002, this required the logic for determining whether SIGPIPE was generated to be pushed down from dofilewrite() to the socket layer so that the socket options could be considered. However, the change in 2002 omitted modification to soo_write() required to add that logic, resulting in SIGPIPE not being generated even without SO_NOSIGPIPE when the socket was written to using write() or related generic system calls. This change adds the EPIPE logic to soo_write(), generating a SIGPIPE signal to the process associated with the passed uio in the event that the SO_NOSIGPIPE option is not set. Notes: - The are upsides and downsides to placing this logic in the socket layer as opposed to the file descriptor layer. This is really fd layer logic, but because we need so_options, we have a choice of layering violations and pick this one. - SIGPIPE possibly should be delivered to the thread performing the write, not the process performing the write. - uio->uio_td and the td argument to soo_write() might potentially differ; we use the thread in the uio argument. - The "sigpipe" regression test in src/tools/regression/sockets/sigpipe tests for the bug. Submitted by: Mikko Tyolajarvi Talked with: glebius, alfred PR: 78478 Approved by: re (scottl)

MFC revisions 1.64 - 1.66

2005-02-27T02:43:51Z

- filedesc locking cleanup.

MFC: /*- and related license changes

2005-01-31T23:27:04Z

Push Giant acquisition down into fo_stat() from most callers. Acquire

2004-07-22T20:40:23Z

Giant conditional on debug.mpsafenet in the socket soo_stat() routine, unconditionally in vn_statfile() for VFS, and otherwise don't acquire Giant. Accept an unlocked read in kqueue_stat(), and cryptof_stat() is a no-op. Don't acquire Giant in fstat() system call. Note: in fdescfs, fo_stat() is called while holding Giant due to the VFS stack sitting on top, and therefore there will still be Giant recursion in this case.

Push acquisition of Giant from fdrop_closed() into fo_close() so that

2004-07-22T18:35:43Z

individual file object implementations can optionally acquire Giant if they require it: - soo_close(): depends on debug.mpsafenet - pipe_close(): Giant not acquired - kqueue_close(): Giant required - vn_close(): Giant required - cryptof_close(): Giant required (conservative) Notes: Giant is still acquired in close() even when closing MPSAFE objects due to kqueue requiring Giant in the calling closef() code. Microbenchmarks indicate that this removal of Giant cuts 3%-3% off of pipe create/destroy pairs from user space with SMP compiled into the kernel. The cryptodev and opencrypto code appears MPSAFE, but I'm unable to test it extensively and so have left Giant over fo_close(). It can probably be removed given some testing and review.

Annotate two intentionally unlocked reads with comments.

2004-06-20T17:35:50Z

Annotate a potentially inconsistent result returned to user space when performing fstaT() on a socket due to not using socket buffer locking.

Merge additional socket buffer locking from rwatson_netperf:

2004-06-17T22:48:11Z

- 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 related

2004-06-14T18:16:22Z

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.

Socket MAC labels so_label and so_peerlabel are now protected by

2004-06-13T02:50:07Z

SOCK_LOCK(so): - Hold socket lock over calls to MAC entry points reading or manipulating socket labels. - Assert socket lock in MAC entry point implementations. - When externalizing the socket label, first make a thread-local copy while holding the socket lock, then release the socket lock to externalize to userspace.

Remove advertising clause from University of California Regent's license,

2004-04-05T21:03:37Z

per letter dated July 22, 1999. Approved by: core