[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.11.1505201050590.1557@ja.home.ssi.bg>
Date: Wed, 20 May 2015 11:07:27 +0300 (EEST)
From: Julian Anastasov <ja@....bg>
To: Ying Xue <ying.xue@...driver.com>
cc: Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org,
davem@...emloft.net, alexei@...estorage.com, joern@...estorage.com
Subject: Re: [PATCH v2] net: fix a double free issue for neighbour entry
Hello,
On Wed, 20 May 2015, Ying Xue wrote:
> On 05/20/2015 01:27 PM, Eric Dumazet wrote:
> > Sorry, this atomic_read() makes no sense to me.
> >
> > When rcu is used, this is perfectly fine to use an object which refcount
> > is 0. If you believe the opposite, then point me to relevant
> > Documentation/RCU/ file.
> >
>
> However, the reality for us is that rcu_read_lock() can guarantee that a neigh
> object is not freed within the area covered by rcu read lock, but it cannot
> prevent neigh_destroy() from being executed in another context at the same time.
The situation is that one writer decided that
entry is to be removed. Reader comes and tries to become
second writer. It should check refcnt==0 or dead==1 as
in your last patch, always under write_lock. Second and next
writers should not try to change state, timers, etc.
Such writers are possible only if they were readers because
only they can find entry that is unlinked by another writer.
And we want to keep the readers free of any memory
barriers as they can cost hundreds of clocks. We are lucky
that the neigh states allow RCU readers to run without any
atomic_inc_not_zero calls because memory barriers are not
cheap.
Regards
--
Julian Anastasov <ja@....bg>
--
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