linux-kernel - Re: [PATCH] Generic percpu refcounting

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] [day] [month] [year] [list]

Date:	Wed, 5 Jun 2013 00:44:12 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Kent Overstreet <koverstreet@...gle.com>,
	linux-kernel@...r.kernel.org, Zach Brown <zab@...hat.com>,
	Felipe Balbi <balbi@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Mark Fasheh <mfasheh@...e.com>,
	Joel Becker <jlbec@...lplan.org>, Jens Axboe <axboe@...nel.dk>,
	Asai Thambi S P <asamymuthupa@...ron.com>,
	Selvan Mani <smani@...ron.com>,
	Sam Bradshaw <sbradshaw@...ron.com>,
	Jeff Moyer <jmoyer@...hat.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Benjamin LaHaise <bcrl@...ck.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Paul McKenney <paul.mckenney@...ibm.com>
Subject: Re: [PATCH] Generic percpu refcounting

On Wed, Jun 05, 2013 at 05:05:09PM +0930, Rusty Russell wrote:
> I think this should be rcu_read_lock(), which is currently equivalent
> but theoretically different.

I suggested using preempt_disable/enable() along with sched RCU.  I
thought that was better for some reason but I was probably
misremembering something.  rcu_read_lock/unlock() w/ synchronize_rcu()
should be fine too.  I don't care either way.

> Does your percpu_ref_kill() *really* need to be nonblocking?  (I'd have
> to read your other patches which use this to be sure).  Otherwise, just
> use synchronize_rcu(), and get rid of the release function...

synchronize_rcu() can always become problematic and should always be
avoided for generic things which may be used in various ways.  They
develop into very long latencies pretty quickly when chained back to
back.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/