linux-kernel - Re: [KVM PATCH v2 2/4] kvm: add return value to kvm_io_bus_register

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]

Date:	Sun, 17 May 2009 22:31:28 -0400
From:	Gregory Haskins <ghaskins@...ell.com>
To:	Avi Kivity <avi@...hat.com>
CC:	kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [KVM PATCH v2 2/4] kvm: add return value to kvm_io_bus_register_dev

Avi Kivity wrote:
> Gregory Haskins wrote:
>> Today this function returns void and will internally BUG_ON if it fails.
>> We want to create dynamic MMIO/PIO entries driven from userspace
>> later in
>> the series, so enhance this API to return an error code on failure.
>>
>> We also fix up all the callsites to check the return code and BUG_ON if
>> it fails.
>>
>> The net result should be identical behavior both before and after this
>> patch.  We are simply laying the groundwork for the dynamic usage
>>   
>
> What happens if the dynamic user gets in there first, then the
> internal device (which is set up by userspace)?  We'll just BUG().

Hmm..I was assuming the in-kernel stuff would have completed in early
init before the dynamic stuff could even get in there.  But thinking
about it some more, you are right.  Theres no reason why something like
a iosignalfd ioctl couldnt come down before, for instance, enabling the
in-kernel PIC.  My bad.


>
> Need to handle the failure gracefully, more or less.
>

Yeah, agreed.  Will fix in next rev.

-Greg



Download attachment "signature.asc" of type "application/pgp-signature" (267 bytes)