| 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: <200804200246.00282.rusty@rustcorp.com.au> Date: Sun, 20 Apr 2008 02:45:59 +1000 From: Rusty Russell <rusty@...tcorp.com.au> To: Evgeniy Polyakov <johnpol@....mipt.ru> Cc: netdev@...r.kernel.org, Max Krasnyansky <maxk@...lcomm.com>, virtualization@...ts.linux-foundation.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 2/5] /dev/vring: simple userspace-kernel ringbuffer interface. On Sunday 20 April 2008 02:33:22 Evgeniy Polyakov wrote: > On Sun, Apr 20, 2008 at 02:05:31AM +1000, Rusty Russell (rusty@...tcorp.com.au) wrote: > > There are two reasons not to grab the lock. It turns out that if we > > tried to lock here, we'd deadlock, since the callbacks are called under > > the lock. Secondly, it's possible to implement an atomic > > vring_used_buffer variant, which could fail: this would avoid using the > > thread most of the time. > > Yep, I decided that too. But it limits its usage to tun only or any > other system where only single thread picks up results, so no generic > userspace ring buffers? I don't think so, it just externalizes the locking. The mutex protects the attaching and detaching of the ops structure, some other lock or code protects simultenous kernel ring accesses. Cheers, Rusty. -- 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