linux-kernel - Re: [KVM PATCH v4 3/3] kvm: add iosignalfd support

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: <4A1D2DD8.2050709@redhat.com>
Date:	Wed, 27 May 2009 15:11:04 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Gregory Haskins <ghaskins@...ell.com>
CC:	kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	Davide Libenzi <davidel@...ilserver.org>, mtosatti@...hat.com,
	Mark McLoughlin <markmc@...hat.com>
Subject: Re: [KVM PATCH v4 3/3] kvm: add iosignalfd support

Gregory Haskins wrote:
>
>> What happens if you register to iosignalfds for the same address but
>> with different cookies (a very practical scenario)?
>>     
>
> This is really only supported at the iosignal interface level.  Today,
> you can do this and the registration will succeed, but at run-time an
> IO-exit will stop at the first in_range() hit it finds.  Therefore, you
> will only get service on the first/lowest registered range.
>
> I knew this was a limitation of the current io_bus, but I put the
> feature into iosignalfd anyway so that the user/kern interface was
> robust enough to support the notion should we ever need it (and can thus
> patch io_bus at that time).  Perhaps that is short-sighted because
> userspace would never know its ranges weren't really registered properly.
>
> I guess its simple enough to have io_bus check all devices for a match
> instead of stopping on the first.  Should I just make a patch to fix
> this, or should I fix iosignalfd to check for in_range matches and fail
> if it finds overlap?  (We could then add a CAP_OVERLAP_IO bit in the
> future if we finally fix the io_bus capability).  I am inclined to lean
> towards option 2, since its not known whether this will ever be useful,
> and io_bus scanning is in a hot-path.
>
> Thinking about it some more, I wonder if we should just get rid of the
> notion of overlap to begin with.  Its a slippery slope (should we also
> return to userspace after scanning and matching io_bus to see if it has
> any overlap too?).  I am not sure if it would ever be used (real
> hardware doesn't have multiple devices at the same address), and we can
> always have multiple end-points mux from one iosignalfd if we really
> need that.  Thoughts?
>   

Multiple cookies on the same address are required by virtio.  You can't 
mux since the data doesn't go anywhere.

Virtio can survive by checking all rings on a notify, and we can later 
add a mechanism that has a distinct address for each ring, but let's see 
if we can cope with multiple cookies.  Mark?

You could search existing iosignalfds for the same address and re-use 
the same iodevice.  I don't want to search the entire list since that 
precludes tricks like using hashtables or sorting the list by frequency 
of access.

-- 
error compiling committee.c: too many arguments to function

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