[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5983241.9X7tkM4Yyi@cpaasch-mac>
Date: Mon, 20 Aug 2012 14:11:08 +0200
From: Christoph Paasch <christoph.paasch@...ouvain.be>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH] ipv4: Use netinet->inet_opt in inet_csk_route_child_sock()
On Monday 20 August 2012 02:51:47 David Miller wrote:
> From: Christoph Paasch <christoph.paasch@...ouvain.be>
> Date: Fri, 17 Aug 2012 23:35:12 +0200
>
> > @@ -404,7 +404,7 @@ struct dst_entry *inet_csk_route_child_sock(struct
> > sock *sk,>
> > {
> > const struct inet_request_sock *ireq = inet_rsk(req);
> > struct inet_sock *newinet = inet_sk(newsk);
> >
> > - struct ip_options_rcu *opt = ireq->opt;
> > + struct ip_options_rcu *opt = rcu_dereference(newinet->inet_opt);
> >
> > struct net *net = sock_net(sk);
>
> 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
--
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists