litmus-rt.git/net/rxrpc, branch tracing-devel

net: Make setsockopt() optlen be unsigned.

2009-09-30T23:12:20+00:00

This provides safety against negative optlen at the type
level instead of depending upon (sometimes non-trivial)
checks against this sprinkled all over the the place, in
each and every implementation.

Based upon work done by Arjan van de Ven and feedback
from Linus Torvalds.

Signed-off-by: David S. Miller

trivial: fix typo "to to" in multiple files

2009-09-21T13:14:55+00:00

Signed-off-by: Anand Gadiyar 
Signed-off-by: Jiri Kosina

RxRPC: Use uX/sX rather than uintX_t/intX_t types

2009-09-16T07:01:13+00:00

Use uX rather than uintX_t types for consistency.

Signed-off-by: David Howells 
Signed-off-by: David S. Miller

RxRPC: Parse security index 5 keys (Kerberos 5)

2009-09-15T09:44:33+00:00

Parse RxRPC security index 5 type keys (Kerberos 5 tokens).

Signed-off-by: David Howells 
Signed-off-by: David S. Miller

RxRPC: Allow RxRPC keys to be read

2009-09-15T09:44:28+00:00

Allow RxRPC keys to be read.  This is to allow pioctl() to be implemented in
userspace.  RxRPC keys are read out in XDR format.

Signed-off-by: David Howells 
Signed-off-by: David S. Miller

RxRPC: Allow key payloads to be passed in XDR form

2009-09-15T09:44:23+00:00

Allow add_key() and KEYCTL_INSTANTIATE to accept key payloads in XDR form as
described by openafs-1.4.10/src/auth/afs_token.xg.  This provides a way of
passing kaserver, Kerberos 4, Kerberos 5 and GSSAPI keys from userspace, and
allows for future expansion.

Signed-off-by: David Howells 
Signed-off-by: David S. Miller

RxRPC: Declare the security index constants symbolically

2009-09-15T09:44:17+00:00

Declare the security index constants symbolically rather than just referring
to them numerically.

Signed-off-by: David Howells 
Signed-off-by: David S. Miller

net: mark read-only arrays as const

2009-08-05T17:42:58+00:00

String literals are constant, and usually, we can also tag the array
of pointers const too, moving it to the .rodata section.

Signed-off-by: Jan Engelhardt 
Signed-off-by: David S. Miller

net: adding memory barrier to the poll and receive callbacks

2009-07-10T00:06:57+00:00

Adding memory barrier after the poll_wait function, paired with
receive callbacks. Adding fuctions sock_poll_wait and sk_has_sleeper
to wrap the memory barrier.

Without the memory barrier, following race can happen.
The race fires, when following code paths meet, and the tp->rcv_nxt
and __add_wait_queue updates stay in CPU caches.

CPU1                         CPU2

sys_select                   receive packet
  ...                        ...
  __add_wait_queue           update tp->rcv_nxt
  ...                        ...
  tp->rcv_nxt check          sock_def_readable
  ...                        {
  schedule                      ...
                                if (sk->sk_sleep && waitqueue_active(sk->sk_sleep))
                                        wake_up_interruptible(sk->sk_sleep)
                                ...
                             }

If there was no cache the code would work ok, since the wait_queue and
rcv_nxt are opposit to each other.

Meaning that once tp->rcv_nxt is updated by CPU2, the CPU1 either already
passed the tp->rcv_nxt check and sleeps, or will get the new value for
tp->rcv_nxt and will return with new data mask.
In both cases the process (CPU1) is being added to the wait queue, so the
waitqueue_active (CPU2) call cannot miss and will wake up CPU1.

The bad case is when the __add_wait_queue changes done by CPU1 stay in its
cache, and so does the tp->rcv_nxt update on CPU2 side.  The CPU1 will then
endup calling schedule and sleep forever if there are no more data on the
socket.

Calls to poll_wait in following modules were ommited:
	net/bluetooth/af_bluetooth.c
	net/irda/af_irda.c
	net/irda/irnet/irnet_ppp.c
	net/mac80211/rc80211_pid_debugfs.c
	net/phonet/socket.c
	net/rds/af_rds.c
	net/rfkill/core.c
	net/sunrpc/cache.c
	net/sunrpc/rpc_pipe.c
	net/tipc/socket.c

Signed-off-by: Jiri Olsa 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

RxRPC: Don't attempt to reuse aborted connections

2009-06-17T04:20:14+00:00

Connections that have seen a connection-level abort should not be reused
as the far end will just abort them again; instead a new connection
should be made.

Connection-level aborts occur due to such things as authentication
failures.

Signed-off-by: David Howells 
Signed-off-by: Linus Torvalds