Re: [PATCH 0/2] eventfd: new EFD_STATE flag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 06, 2010 at 03:59:11PM -0800, Davide Libenzi wrote:
> On Thu, 7 Jan 2010, Michael S. Tsirkin wrote:
> 
> > On Wed, Jan 06, 2010 at 02:46:06PM -0800, Davide Libenzi wrote:
> > > On Thu, 7 Jan 2010, Michael S. Tsirkin wrote:
> > > 
> > > > > On top of creating an interface which requires a lock, which noone can get 
> > > > > from the interface itself, since it's not exposed.
> > > > 
> > > > I think here's how KVM gets it: the way it does is by calling poll with
> > > > our own poll table, then in poll_queue_proc we get wait queue pointer,
> > > > and we use the wait queue. Lock is in there :)
> > > 
> > > Yes, I know you are called locked, but it does not lead to a clean 
> > > interface.
> > 
> > True.
> > 
> > > > > I could split the two and have a locked one, and an unlocked one, but that 
> > > > > looks shitty too (for the above reason).
> > > > 
> > > > Yes, this will work. Thanks!
> > > 
> > > This is a lot more complex than I thought. The wakeup code is already 
> > > enumerating the list, and doing a wakeup might trigger a secondary 
> > > enumeration/recursion.
> > 
> > For KVM what you describe is I think is not a problem: we check wake type
> > and ignore POLLOUT events.
> 
> You seem to think in one dimension only ;)
> The interface needs to be stable for everyone.
> 

I agree it's better to have interface that can't be misused.  I was just
pointing out that users *can* break recursion by looking at event type.

> > Maybe yes. I'll think it over and get back to you. Thanks!
> 
> Let me know.
> 
> 
> 
> - Davide
> 
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux