From: Christoph Paasch <hidden> Date: 2012-08-17 21:35:25
Since 0e734419923bd ("ipv4: Use inet_csk_route_child_sock() in DCCP and
TCP."), inet_csk_route_child_sock() is called instead of
inet_csk_route_req().
However, after creating the child-sock in tcp/dccp_v4_syn_recv_sock(),
ireq->opt is set to NULL, before calling inet_csk_route_child_sock().
Thus, inside inet_csk_route_child_sock() opt is always NULL and the
SRR-options are not respected anymore.
Packets sent by the server won't have the correct destination-IP.
This patch fixes it by accessing newinet->inet_opt instead of ireq->opt
inside inet_csk_route_child_sock().
Signed-off-by: Christoph Paasch <redacted>
---
net/ipv4/inet_connection_sock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
We're not inside of a rcu_read_lock() protected section, so this access
is not legitimate. If you enabled RCU lock debugging, you would have
triggered a warning in the kernel log.
We're not inside of a rcu_read_lock() protected section, so this access
is not legitimate. If you enabled RCU lock debugging, you would have
triggered a warning in the kernel log.
Oh, sorry... I will resubmit a v2.
Although, I enabled CONFIG_PROVE_RCU (and all other RCU-related debug I could
find) and no warning was triggered.
By the way, in dccp_v4_request_recv_sock() is the code:
newinet->inet_opt = ireq->opt;
Shouldn't this rather be an rcu_assign_pointer() ?
And in cipso_v4_sock_delattr() I believe we should also rather access 'opt'
instead of doing cipso_v4_delopt(&sk_inet->inet_opt) ?
Christoph
--
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be
Université Catholique de Louvain
--