lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ