| 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
| ||
|
Message-ID: <loom.20090311T151357-544@post.gmane.org> Date: Wed, 11 Mar 2009 17:13:47 +0000 (UTC) From: Dmitriy V\'jukov <dvyukov@...il.com> To: linux-kernel@...r.kernel.org Subject: Re: SRCU: Number of outstanding callbacks Paul E. McKenney <paulmck <at> linux.vnet.ibm.com> writes: > The short answer is, as you guessed, because it is not (yet) worth doing. > This is at least in part because SRCU is not heavily used. > > The philosophy behind the limitation is that the memory overhead of > the blocks is a small fraction of the memory required to represent > a thread. As you say, there are a number of other strategies that can > be pursued, but the current strategy has the advantage of simplicity. > In particular, the current strategy does not require a failure return > from an as-yet-nonexistent call_srcu(). Handling such a failure return > is certainly possible, but someone would have to show me an extremely > good reason for putting up with this. Yes, I've noticed the extreme simplicity of the current synchronize_srcu(). As for failure return from call_srcu(), I think it's possible to just call synchronize_srcu() from inside call_srcu() if the latter encounters any errors. Anyway call_srcu() will be "sometimes blocking" because of the limit on number of outstanding callbacks, so this must not be a problem. -- Best regards, Dmitriy V'jukov -- 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/
Powered by blists - more mailing lists