linux-kernel - Re: [KVM-RFC PATCH 1/2] eventfd: add an explicit srcu based notifier interface

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

Message-ID: <alpine.DEB.1.10.0906170932290.7891@makko.or.mcafeemobile.com>
Date:	Wed, 17 Jun 2009 09:38:55 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Gregory Haskins <ghaskins@...ell.com>
cc:	"Michael S. Tsirkin" <mst@...hat.com>, kvm@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	avi@...hat.com, paulmck@...ux.vnet.ibm.com,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [KVM-RFC PATCH 1/2] eventfd: add an explicit srcu based notifier
 interface

On Tue, 16 Jun 2009, Gregory Haskins wrote:

> Davide Libenzi wrote:
> > On Tue, 16 Jun 2009, Gregory Haskins wrote:
> >
> >   
> >> Does this all make sense?
> >>     
> >
> > This conversation has been *really* long, and I haven't had time to look 
> > at the patch yet. But looking at the amount of changes, and the amount of 
> > even more changes talked in this thread, there's a very slim chance that 
> > I'll ACK the eventfd code.
> > You may want to consider a solution that does not litter eventfd code that 
> > much.
> >
> >
> > - Davide
> >
> >
> >   
> Hi Davide,
> 
> I understand your position and value your time/insight into looking at
> this things.
> 
> Despite the current ongoing discussion, I still stand that the current
> patch is my proposed solution (though I have yet to convince Michael). 
> But in any case,  if you have the time, please look it over because I
> still think its the right direction to head in.

I don't think so. You basically upload a bunch of stuff it could have been 
inside your irqfd into eventfd. Now the eventfd_signal() can magically 
sleep, or not, depending on what the signal functions do. This makes up a 
pretty aweful interface if you ask me.
A lot simpler and cleaner if eventfd_signal(), like all the wake up 
functions inside the kernel, can be called from atomic context. Always, 
not sometimes.



- Davide


--
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/