[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A524701.3020808@novell.com>
Date: Mon, 06 Jul 2009 14:48:33 -0400
From: Gregory Haskins <ghaskins@...ell.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
CC: Avi Kivity <avi@...hat.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, davidel@...ilserver.org
Subject: Re: [KVM PATCH v9 0/5] irqfd fixes and enhancements
Michael S. Tsirkin wrote:
> On Mon, Jul 06, 2009 at 12:41:59PM -0400, Gregory Haskins wrote:
>
>> Michael S. Tsirkin wrote:
>>
>>>>
>>>>
>>> wouldn't it be cleaner to error out in the for each loop if we don't
>>> find an entry to deactivate? Might be helpful for apps to get an error
>>> if they didn't deassign anything.
>>>
>>>
>> Again, irqfds.init is somewhat orthogonal to whether the list is
>> populated or not. This check is for sanity (how can you deassign if you
>> didnt assign, etc). Normally this would be a simple BUG_ON() sanity
>> check, but I don't want a malicious/broken userspace to gain an easy
>> attack vector ;)
>>
>
> what I'm saying is that deassign should return an error if it's passed
> and entry that is not on the list.
This isn't an unreasonable request, and I believe this is actually the
way the original deassign logic worked before we yanked the feature a
few weeks ago. Its only slightly complicated by the fact that we may
match multiple irqfds, but I think we solved that before by returning
the number we matched.
If Avi answers the other mail stating he wants to still see the
on-demand work go in, lets use your suggestion.
Regards,
-Greg
Download attachment "signature.asc" of type "application/pgp-signature" (267 bytes)
Powered by blists - more mailing lists