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:
signature.asc
Description: OpenPGP digital signature
