From: Gregory Haskins <ghaskins@novell.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Avi Kivity <avi@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
davidel@xmailserver.org
Subject: Re: [KVM PATCH v9 0/5] irqfd fixes and enhancements
Date: Mon, 06 Jul 2009 14:48:33 -0400 [thread overview]
Message-ID: <4A524701.3020808@novell.com> (raw)
In-Reply-To: <20090706164955.GE12399@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]
prev parent reply other threads:[~2009-07-06 18:48 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-02 15:37 [KVM PATCH v9 0/5] irqfd fixes and enhancements Gregory Haskins
2009-07-02 15:38 ` [KVM PATCH v9 1/5] kvm: prepare irqfd for having interrupts disabled during eventfd->release Gregory Haskins
2009-07-02 15:38 ` [KVM PATCH v9 2/5] eventfd: use locked POLLHUP Gregory Haskins
2009-07-02 16:43 ` Davide Libenzi
2009-07-02 15:38 ` [KVM PATCH v9 3/5] KVM: Fix races in irqfd using new eventfd_kref_get interface Gregory Haskins
2009-07-02 15:38 ` [KVM PATCH v9 4/5] KVM: add irqfd DEASSIGN feature Gregory Haskins
2009-07-02 15:38 ` [KVM PATCH v9 5/5] KVM: create irqfd-cleanup-wq on demand Gregory Haskins
2009-07-06 15:58 ` Michael S. Tsirkin
2009-07-06 16:03 ` Gregory Haskins
2009-07-06 16:14 ` Michael S. Tsirkin
2009-07-06 16:32 ` Gregory Haskins
2009-07-06 16:50 ` Michael S. Tsirkin
2009-07-06 18:28 ` Gregory Haskins
2009-07-07 5:17 ` Avi Kivity
2009-07-07 11:26 ` Gregory Haskins
2009-07-02 15:50 ` [KVM PATCH v9 0/5] irqfd fixes and enhancements Avi Kivity
2009-07-05 9:28 ` Avi Kivity
2009-07-05 10:16 ` Michael S. Tsirkin
2009-07-05 10:20 ` Michael S. Tsirkin
2009-07-05 10:38 ` Michael S. Tsirkin
2009-07-05 10:42 ` Avi Kivity
2009-07-05 21:21 ` Gregory Haskins
2009-07-06 14:56 ` Gregory Haskins
2009-07-06 16:13 ` Michael S. Tsirkin
2009-07-06 16:41 ` Gregory Haskins
2009-07-06 16:49 ` Michael S. Tsirkin
2009-07-06 18:48 ` Gregory Haskins [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A524701.3020808@novell.com \
--to=ghaskins@novell.com \
--cc=avi@redhat.com \
--cc=davidel@xmailserver.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox