linux-toradex.git/net/rds/send.c, branch v4.4.101

RDS: RDMA: Fix the composite message user notification

2017-10-08T08:14:16+00:00

[ Upstream commit 941f8d55f6d613a460a5e080d25a38509f45eb75 ]

When application sends an RDS RDMA composite message consist of
RDMA transfer to be followed up by non RDMA payload, it expect to
be notified *only* when the full message gets delivered. RDS RDMA
notification doesn't behave this way though.

Thanks to Venkat for debug and root casuing the issue
where only first part of the message(RDMA) was
successfully delivered but remainder payload delivery failed.
In that case, application should not be notified with
a false positive of message delivery success.

Fix this case by making sure the user gets notified only after
the full message delivery.

Reviewed-by: Venkat Venkatsubra 
Signed-off-by: Santosh Shilimkar 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

RDS: fix race condition when sending a message on unbound socket

2015-11-24T22:20:09+00:00

Sasha's found a NULL pointer dereference in the RDS connection code when
sending a message to an apparently unbound socket.  The problem is caused
by the code checking if the socket is bound in rds_sendmsg(), which checks
the rs_bound_addr field without taking a lock on the socket.  This opens a
race where rs_bound_addr is temporarily set but where the transport is not
in rds_bind(), leading to a NULL pointer dereference when trying to
dereference 'trans' in __rds_conn_create().

Vegard wrote a reproducer for this issue, so kindly ask him to share if
you're interested.

I cannot reproduce the NULL pointer dereference using Vegard's reproducer
with this patch, whereas I could without.

Complete earlier incomplete fix to CVE-2015-6937:

  74e98eb08588 ("RDS: verify the underlying transport exists before creating a connection")

Cc: David S. Miller 
Cc: stable@vger.kernel.org

Reviewed-by: Vegard Nossum 
Reviewed-by: Sasha Levin 
Acked-by: Santosh Shilimkar 
Signed-off-by: Quentin Casasnovas 
Signed-off-by: David S. Miller

RDS: fix rds-ping deadlock over TCP transport

2015-10-19T05:45:55+00:00

Sowmini found hang with rds-ping while testing RDS over TCP. Its
a corner case and doesn't happen always. The issue is not reproducible
with IB transport. Its clear from below dump why we see it with RDS TCP.

 [] do_tcp_setsockopt+0xb5/0x740
 [] tcp_setsockopt+0x24/0x30
 [] sock_common_setsockopt+0x14/0x20
 [] rds_tcp_xmit_prepare+0x5d/0x70 [rds_tcp]
 [] rds_send_xmit+0xd7/0x740 [rds]
 [] rds_send_pong+0x142/0x180 [rds]
 [] rds_recv_incoming+0x274/0x330 [rds]
 [] ? ttwu_queue+0x11e/0x130
 [] ? skb_copy_bits+0x6d/0x2c0
 [] rds_tcp_data_recv+0x2f0/0x3d0 [rds_tcp]
 [] tcp_read_sock+0x96/0x1c0
 [] ? rds_tcp_recv_init+0x40/0x40 [rds_tcp]
 [] ? sock_def_write_space+0xa0/0xa0
 [] rds_tcp_data_ready+0xa1/0xf0 [rds_tcp]
 [] tcp_data_queue+0x379/0x5b0
 [] ? rds_tcp_write_space+0xbb/0x110 [rds_tcp]
 [] tcp_rcv_established+0x2e2/0x6e0
 [] tcp_v4_do_rcv+0x122/0x220
 [] tcp_v4_rcv+0x867/0x880
 [] ip_local_deliver_finish+0xa3/0x220

This happens because rds_send_xmit() chain wants to take
sock_lock which is already taken by tcp_v4_rcv() on its
way to rds_tcp_data_ready(). Commit db6526dcb51b ("RDS: use
rds_send_xmit() state instead of RDS_LL_SEND_FULL") which
was trying to opportunistically finish the send request
in same thread context.

But because of above recursive lock hang with RDS TCP,
the send work from rds_send_pong() needs to deferred to
worker to avoid lock up. Given RDS ping is more of connectivity
test than performance critical path, its should be ok even
for transport like IB.

Reported-by: Sowmini Varadhan 
Acked-by:  Sowmini Varadhan 
Signed-off-by: Santosh Shilimkar 
Signed-off-by: Santosh Shilimkar 
Acked-by: Sowmini Varadhan 
Signed-off-by: David S. Miller

RDS: IB: split send completion handling and do batch ack

2015-10-05T18:19:01+00:00

Similar to what we did with receive CQ completion handling, we split
the transmit completion handler so that it lets us implement batched
work completion handling.

We re-use the cq_poll routine and makes use of RDS_IB_SEND_OP to
identify the send vs receive completion event handler invocation.

Signed-off-by: Santosh Shilimkar 
Signed-off-by: Santosh Shilimkar

RDS: use rds_send_xmit() state instead of RDS_LL_SEND_FULL

2015-10-05T18:19:01+00:00

In Transport indepedent rds_sendmsg(), we shouldn't make decisions based
on RDS_LL_SEND_FULL which is used to manage the ring for RDMA based
transports. We can safely issue rds_send_xmit() and the using its
return value take decision on deferred work. This will also fix
the scenario where at times we are seeing connections stuck with
the LL_SEND_FULL bit getting set and never cleared.

We kick krdsd after any time we see -ENOMEM or -EAGAIN from the
ring allocation code.

Signed-off-by: Santosh Shilimkar 
Signed-off-by: Santosh Shilimkar

RDS: defer the over_batch work to send worker

2015-10-05T18:18:45+00:00

Current process gives up if its send work over the batch limit.
The work queue will get  kicked to finish off any other requests.
This fixes remainder condition from commit 443be0e5affe ("RDS: make
sure not to loop forever inside rds_send_xmit").

The restart condition is only for the case where we reached to
over_batch code for some other reason so just retrying again
before giving up.

While at it, make sure we use already available 'send_batch_count'
parameter instead of magic value. The batch count threshold value
of 1024 came via commit 443be0e5affe ("RDS: make sure not to loop
forever inside rds_send_xmit"). The idea is to process as big a
batch as we can but at the same time we don't hold other waiting
processes for send. Hence back-off after the send_batch_count
limit (1024) to avoid soft-lock ups.

Signed-off-by: Santosh Shilimkar 
Signed-off-by: Santosh Shilimkar

RDS: return EMSGSIZE for oversize requests before processing/queueing

2015-08-25T20:35:31+00:00

rds_send_queue_rm() allows for the "current datagram" being queued
to exceed SO_SNDBUF thresholds by checking bytes queued without
counting in length of current datagram. (Since sk_sndbuf is set
to twice requested SO_SNDBUF value as a kernel heuristic this
is usually fine!)

If this "current datagram" squeezing past the threshold is itself
many times the size of the sk_sndbuf threshold itself then even
twice the SO_SNDBUF does not save us and it gets queued but
cannot be transmitted. Threads block and deadlock and device
becomes unusable. The check for this datagram not exceeding
SNDBUF thresholds (EMSGSIZE) is not done on this datagram as
that check is only done if queueing attempt fails.
(Datagrams that follow this datagram fail queueing attempts, go
through the check and eventually trip EMSGSIZE error but zero
length datagrams silently fail!)

This fix moves the check for datagrams exceeding SNDBUF limits
before any processing or queueing is attempted and returns EMSGSIZE
early in the rds_sndmsg() code. This change also ensures that all
datagrams get checked for exceeding SNDBUF/sk_sndbuf size limits
and the large datagrams that exceed those limits do not get to
rds_send_queue_rm() code for processing.

Signed-off-by: Mukesh Kacker 
Signed-off-by: Santosh Shilimkar 
Signed-off-by: Santosh Shilimkar 
Signed-off-by: David S. Miller

RDS: make sure rds_send_drop_to properly takes the m_rs_lock

2015-08-25T20:35:31+00:00

rds_send_drop_to() is used during socket tear down to find all the
messages on the socket and flush them .  It can race with the
acking code unless it takes the m_rs_lock on each and every message.

This plugs a hole where we didn't take m_rs_lock on any message that
didn't have the RDS_MSG_ON_CONN set.  Taking m_rs_lock avoids
double frees and other memory corruptions as the ack code trusts
the message m_rs pointer on a socket that had actually been freed.

We must take m_rs_lock to access m_rs.  Because of lock nesting and
rs access, we also need to acquire rs_lock.

Reviewed-by: Ajaykumar Hotchandani 
Signed-off-by: Santosh Shilimkar 
Signed-off-by: Santosh Shilimkar 
Signed-off-by: David S. Miller

RDS: Mark message mapped before transmit

2015-08-25T20:35:30+00:00

rds_send_xmit() marks the rds message map flag after
xmit_[rdma/atomic]() which is clearly wrong.  We need
to maintain the ownership between transport and rds.

Also take care of error path.

Reviewed-by: Ajaykumar Hotchandani 
Signed-off-by: Santosh Shilimkar 
Signed-off-by: Santosh Shilimkar 
Signed-off-by: David S. Miller

RDS: check for congestion updates during rds_send_xmit

2015-08-25T20:35:30+00:00

Ensure we don't keep sending the data if the link is congested.

Reviewed-by: Ajaykumar Hotchandani 
Signed-off-by: Santosh Shilimkar 
Signed-off-by: Santosh Shilimkar 
Signed-off-by: David S. Miller