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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 10 Jul 2007 15:10:34 +0200 From: Jarek Poplawski <jarkao2@...pl> To: Patrick McHardy <kaber@...sh.net> Cc: Ranko Zivojnovic <ranko@...dernet.net>, akpm@...ux-foundation.org, netdev@...r.kernel.org Subject: Re: + gen_estimator-fix-locking-and-timer-related-bugs.patch added to -mm tree On Tue, Jul 10, 2007 at 02:20:12PM +0200, Patrick McHardy wrote: > Jarek Poplawski wrote: > > On Tue, Jul 10, 2007 at 01:09:07PM +0300, Ranko Zivojnovic wrote: > > > >>However I decided not to use _rcu based iteration neither the > >>rcu_read_lock() after going through the RCU documentation and a bunch of > >>examples in kernel that iterate through the lists using non _rcu macros > >>and do list_del_rcu() just fine. > >> > >>For readability, the reference to list_del_rcu as well as call_rcu, I > >>believe, should be enough of the indication. Please do correct me if I > >>am wrong here. > > > > > > It's only my opinion, and it's probably not very popular at least > > at net/ code, so it's more about general policy and not this > > particular code. But: > > - if somebody is looking after some rcu related problems, why can't > > he/she spare some time by omitting lists without _rcu and not > > analyzing why/how such lists are used and locked? > > > RCU is used for the read-side, using it on the write-side just makes > things *less* understandable IMO. It will look like the read-side > but still do modifications. > >From Documentation/RCU/checklist: "9. All RCU list-traversal primitives, which include list_for_each_rcu(), list_for_each_entry_rcu(), list_for_each_continue_rcu(), and list_for_each_safe_rcu(), must be within an RCU read-side critical section. RCU read-side critical sections are delimited by rcu_read_lock() and rcu_read_unlock(), or by similar primitives such as rcu_read_lock_bh() and rcu_read_unlock_bh(). Use of the _rcu() list-traversal primitives outside of an RCU read-side critical section causes no harm other than a slight performance degradation on Alpha CPUs. It can also be quite helpful in reducing code bloat when common code is shared between readers and updaters." So, it seems, it's a question of taste about what is this bloat. I'd certainly agree with you if the write-side looks like in examples from documentation: there is always a few lines of code with some spinlocks. But here we see no locks and no comments, so each time we have to guess which of the supposed here locks is needed for RCU or maybe for the lists without "rcu". Sorry, for messing here with my private opinions: I really shouldn't start this theme. Jarek P. - 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