linux-stable.git/net/sctp/input.c, branch linux-4.7.y

sctp: fix BH handling on socket backlog

2016-08-16T07:34:58+00:00

[ Upstream commit eefc1b1d105ee4d2ce907833ce675f1e9599b5e3 ]

Now that the backlog processing is called with BH enabled, we have to
disable BH before taking the socket lock via bh_lock_sock() otherwise
it may dead lock:

sctp_backlog_rcv()
                bh_lock_sock(sk);

                if (sock_owned_by_user(sk)) {
                        if (sk_add_backlog(sk, skb, sk->sk_rcvbuf))
                                sctp_chunk_free(chunk);
                        else
                                backloged = 1;
                } else
                        sctp_inq_push(inqueue, chunk);

                bh_unlock_sock(sk);

while sctp_inq_push() was disabling/enabling BH, but enabling BH
triggers pending softirq, which then may try to re-lock the socket in
sctp_rcv().

[  219.187215]  
[  219.187217]  [] _raw_spin_lock+0x20/0x30
[  219.187223]  [] sctp_rcv+0x48c/0xba0 [sctp]
[  219.187225]  [] ? nf_iterate+0x62/0x80
[  219.187226]  [] ip_local_deliver_finish+0x94/0x1e0
[  219.187228]  [] ip_local_deliver+0x6f/0xf0
[  219.187229]  [] ? ip_rcv_finish+0x3b0/0x3b0
[  219.187230]  [] ip_rcv_finish+0xd8/0x3b0
[  219.187232]  [] ip_rcv+0x282/0x3a0
[  219.187233]  [] ? update_curr+0x66/0x180
[  219.187235]  [] __netif_receive_skb_core+0x524/0xa90
[  219.187236]  [] ? update_cfs_shares+0x30/0xf0
[  219.187237]  [] ? __enqueue_entity+0x6c/0x70
[  219.187239]  [] ? enqueue_entity+0x204/0xdf0
[  219.187240]  [] __netif_receive_skb+0x18/0x60
[  219.187242]  [] process_backlog+0x9e/0x140
[  219.187243]  [] net_rx_action+0x22c/0x370
[  219.187245]  [] __do_softirq+0x112/0x2e7
[  219.187247]  [] do_softirq_own_stack+0x1c/0x30
[  219.187247]  
[  219.187248]  [] do_softirq.part.14+0x38/0x40
[  219.187249]  [] __local_bh_enable_ip+0x7d/0x80
[  219.187254]  [] sctp_inq_push+0x68/0x80 [sctp]
[  219.187258]  [] sctp_backlog_rcv+0x151/0x1c0 [sctp]
[  219.187260]  [] __release_sock+0x87/0xf0
[  219.187261]  [] release_sock+0x30/0xa0
[  219.187265]  [] sctp_accept+0x17d/0x210 [sctp]
[  219.187266]  [] ? prepare_to_wait_event+0xf0/0xf0
[  219.187268]  [] inet_accept+0x3c/0x130
[  219.187269]  [] SYSC_accept4+0x103/0x210
[  219.187271]  [] ? _raw_spin_unlock_bh+0x1a/0x20
[  219.187272]  [] ? release_sock+0x8c/0xa0
[  219.187276]  [] ? sctp_inet_listen+0x62/0x1b0 [sctp]
[  219.187277]  [] SyS_accept+0x10/0x20

Fixes: 860fbbc343bf ("sctp: prepare for socket backlog behavior change")
Cc: Eric Dumazet 
Signed-off-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sctp: load transport header after sk_filter

2016-07-19T05:46:52+00:00

Do not cache pointers into the skb linear segment across sk_filter.
The function call can trigger pskb_expand_head.

Signed-off-by: Willem de Bruijn 
Acked-by: Daniel Borkmann 
Acked-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller

net: rename NET_{ADD|INC}_STATS_BH()

2016-04-28T02:48:24+00:00

Rename NET_INC_STATS_BH() to __NET_INC_STATS()
and NET_ADD_STATS_BH() to __NET_ADD_STATS()

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

net: sctp: rename SCTP_INC_STATS_BH()

2016-04-28T02:48:23+00:00

Rename SCTP_INC_STATS_BH() to __SCTP_INC_STATS()

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

net: rename ICMP_INC_STATS_BH()

2016-04-28T02:48:22+00:00

Rename ICMP_INC_STATS_BH() to __ICMP_INC_STATS()

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

sctp: align MTU to a word

2016-03-20T20:31:12+00:00

SCTP is a protocol that is aligned to a word (4 bytes). Thus using bare
MTU can sometimes return values that are not aligned, like for loopback,
which is 65536 but ipv4_mtu() limits that to 65535. This mis-alignment
will cause the last non-aligned bytes to never be used and can cause
issues with congestion control.

So it's better to just consider a lower MTU and keep congestion control
calcs saner as they are based on PMTU.

Same applies to icmp frag needed messages, which is also fixed by this
patch.

One other effect of this is the inability to send MTU-sized packet
without queueing or fragmentation and without hitting Nagle. As the
check performed at sctp_packet_can_append_data():

if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead)
	/* Enough data queued to fill a packet */
	return SCTP_XMIT_OK;

with the above example of MTU, if there are no other messages queued,
one cannot send a packet that just fits one packet (65532 bytes) and
without causing DATA chunk fragmentation or a delay.

v2:
 - Added WORD_TRUNC macro

Signed-off-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller

sctp: allow sctp_transmit_packet and others to use gfp

2016-03-14T02:29:07+00:00

Currently sctp_sendmsg() triggers some calls that will allocate memory
with GFP_ATOMIC even when not necessary. In the case of
sctp_packet_transmit it will allocate a linear skb that will be used to
construct the packet and this may cause sends to fail due to ENOMEM more
often than anticipated specially with big MTUs.

This patch thus allows it to inherit gfp flags from upper calls so that
it can use GFP_KERNEL if it was triggered by a sctp_sendmsg call or
similar. All others, like retransmits or flushes started from BH, are
still allocated using GFP_ATOMIC.

In netperf tests this didn't result in any performance drawbacks when
memory is not too fragmented and made it trigger ENOMEM way less often.

Signed-off-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller

sctp: move rcu_read_lock from __sctp_lookup_association to sctp_lookup_association

2016-02-17T20:41:54+00:00

__sctp_lookup_association() is only invoked by sctp_v4_err() and
sctp_rcv(), both which run on the rx BH, and it has been protected
by rcu_read_lock [see ip_local_deliver_finish() / ipv6_rcv()].

So we can move it to sctp_lookup_association, only let
sctp_lookup_association use rcu_read_lock.

Signed-off-by: Xin Long 
Signed-off-by: David S. Miller

sctp: fix the transport dead race check by using atomic_add_unless on refcnt

2016-01-28T23:59:32+00:00

Now when __sctp_lookup_association is running in BH, it will try to
check if t->dead is set, but meanwhile other CPUs may be freeing this
transport and this assoc and if it happens that
__sctp_lookup_association checked t->dead a bit too early, it may think
that the association is still good while it was already freed.

So we fix this race by using atomic_add_unless in sctp_transport_hold.
After we get one transport from hashtable, we will hold it only when
this transport's refcnt is not 0, so that we can make sure t->asoc
cannot be freed before we hold the asoc again.

Note that sctp association is not freed using RCU so we can't use
atomic_add_unless() with it as it may just be too late for that either.

Fixes: 4f0087812648 ("sctp: apply rhashtable api to send/recv path")
Reported-by: Vlad Yasevich 
Signed-off-by: Xin Long 
Signed-off-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller

sctp: the temp asoc's transports should not be hashed/unhashed

2016-01-18T00:11:44+00:00

Re-establish the previous behavior and avoid hashing temporary asocs by
checking t->asoc->temp in sctp_(un)hash_transport. Also, remove the
check of t->asoc->temp in __sctp_lookup_association, since they are
never hashed now.

Fixes: 4f0087812648 ("sctp: apply rhashtable api to send/recv path")
Signed-off-by: Xin Long 
Acked-by: Marcelo Ricardo Leitner 
Reported-by: Vlad Yasevich 
Signed-off-by: David S. Miller