From: Ying Xue <ying.xue@windriver.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: <netdev@vger.kernel.org>, <davem@davemloft.net>,
<eric.dumazet@gmail.com>, <alexei@purestorage.com>,
<joern@purestorage.com>
Subject: Re: [PATCH v2] net: fix a double free issue for neighbour entry
Date: Wed, 20 May 2015 17:22:39 +0800 [thread overview]
Message-ID: <555C525F.1040006@windriver.com> (raw)
In-Reply-To: <alpine.LFD.2.11.1505201003150.1557@ja.home.ssi.bg>
On 05/20/2015 03:35 PM, Julian Anastasov wrote:
>
> Hello,
>
> On Wed, 20 May 2015, Ying Xue wrote:
>
>> --- a/net/core/neighbour.c
>> +++ b/net/core/neighbour.c
>> @@ -958,6 +958,9 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
>> if (neigh->nud_state & (NUD_CONNECTED | NUD_DELAY | NUD_PROBE))
>> goto out_unlock_bh;
>>
>> + if (neigh->dead)
>> + goto out_unlock_bh;
>> +
>
> Returning 0 in all cases is wrong.
Good catch!
Yes, you are right. We should return 1 especially when neigh->dead == 1.
May be you can goto
> to another new label where nud_state check can allow valid
> address to be used. See my idea:
>
> http://marc.info/?l=linux-netdev&m=142816363503402&w=2
>
> I.e. return 0 for NUD_STALE, drop skb and return 1
> otherwise.
>
>> if (!(neigh->nud_state & (NUD_STALE | NUD_INCOMPLETE))) {
>> if (NEIGH_VAR(neigh->parms, MCAST_PROBES) +
>> NEIGH_VAR(neigh->parms, APP_PROBES)) {
>> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
>> index c65b93a..5889774 100644
>> --- a/net/ipv4/ip_output.c
>> +++ b/net/ipv4/ip_output.c
>> @@ -200,7 +200,7 @@ static inline int ip_finish_output2(struct sock *sk, struct sk_buff *skb)
>> rcu_read_lock_bh();
>> nexthop = (__force u32) rt_nexthop(rt, ip_hdr(skb)->daddr);
>> neigh = __ipv4_neigh_lookup_noref(dev, nexthop);
>> - if (unlikely(!neigh))
>> + if (unlikely(!neigh || !atomic_read(&neigh->refcnt)))
>
> You should forget about refcnt. kfree_rcu in neigh_destroy
> will not free neigh while RCU readers are present. Still,
> neigh_destroy runs in parallel with readers and I hope they can
> use the stored address safely.
I know touching neigh entry in ip_finish_output2() without identifying if
atomic_read(&neigh->refcnt)==0 under RCU lock is absolutely safe for us. But in
some extent we can say the issue is not much a closely relationship to RCU lock.
The key problem for us is how efficiently we can prevent neigh refcnt from being
increased from 0 to 1 on the path of dst_neigh_output().
Regards,
Ying
I mean, neigh_event_send allowing
> neigh_resolve_output to use address in NUD_STALE state on dead=1
> by returning 0 and reaching the dev_queue_xmit call.
>
> Still, another inefficiency remains: how can
> __neigh_event_send indicate to ip_finish_output2 that
> dead=1 entry is [to be] removed and new entry needs to
> be created. It seems the ->output method returns code
> but skb is freed in all cases. The result is that we
> drop single skb in such condition. But such optimization
> should not be part of this bugfix.
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
>
prev parent reply other threads:[~2015-05-20 9:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-20 1:25 [PATCH v2] net: fix a double free issue for neighbour entry Ying Xue
2015-05-20 5:27 ` Eric Dumazet
2015-05-20 7:01 ` Ying Xue
2015-05-20 8:07 ` Julian Anastasov
2015-05-20 8:39 ` Ying Xue
2015-05-20 19:19 ` Julian Anastasov
2015-05-20 10:45 ` Eric Dumazet
2015-05-20 7:35 ` Julian Anastasov
2015-05-20 9:22 ` Ying Xue [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=555C525F.1040006@windriver.com \
--to=ying.xue@windriver.com \
--cc=alexei@purestorage.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=ja@ssi.bg \
--cc=joern@purestorage.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).