[PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe

[PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe

[Nicholas Krause]

This fixes the error handling in the function vgic_v3_probe
for when calling the function kvm_register_device_ops to check
if the call to this function has returned a error code and if
so jump to the label out with goto to cleanup no longer required
resources used by the function vgic_v3_probe before returning the
error code from the call to kvm_register_device_ops to the caller
of the function vgic_v3_probe.

Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
---
 virt/kvm/arm/vgic-v3.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/virt/kvm/arm/vgic-v3.c b/virt/kvm/arm/vgic-v3.c
index dff0602..5102aa2 100644
--- a/virt/kvm/arm/vgic-v3.c
+++ b/virt/kvm/arm/vgic-v3.c
@@ -264,12 +264,16 @@ int vgic_v3_probe(struct device_node *vgic_node,
 	} else {
 		vgic->vcpu_base = vcpu_res.start;
 		vgic->can_emulate_gicv2 = true;
-		kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
-					KVM_DEV_TYPE_ARM_VGIC_V2);
+		ret = kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
+					      KVM_DEV_TYPE_ARM_VGIC_V2);
+		if (ret)
+			goto out;
 	}
 	if (vgic->vcpu_base == 0)
 		kvm_info("disabling GICv2 emulation\n");
-	kvm_register_device_ops(&kvm_arm_vgic_v3_ops, KVM_DEV_TYPE_ARM_VGIC_V3);
+	ret = kvm_register_device_ops(&kvm_arm_vgic_v3_ops, KVM_DEV_TYPE_ARM_VGIC_V3);
+	if (ret)
+		goto out;
 
 	vgic->vctrl_base = NULL;
 	vgic->type = VGIC_V3;
-- 
2.1.4

[PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe

[Paolo Bonzini]

On 05/08/2015 18:48, Nicholas Krause wrote:
> This fixes the error handling in the function vgic_v3_probe
> for when calling the function kvm_register_device_ops to check
> if the call to this function has returned a error code and if
> so jump to the label out with goto to cleanup no longer required
> resources used by the function vgic_v3_probe before returning the
> error code from the call to kvm_register_device_ops to the caller
> of the function vgic_v3_probe.
> 
> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
> ---
>  virt/kvm/arm/vgic-v3.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/virt/kvm/arm/vgic-v3.c b/virt/kvm/arm/vgic-v3.c
> index dff0602..5102aa2 100644
> --- a/virt/kvm/arm/vgic-v3.c
> +++ b/virt/kvm/arm/vgic-v3.c
> @@ -264,12 +264,16 @@ int vgic_v3_probe(struct device_node *vgic_node,
>  	} else {
>  		vgic->vcpu_base = vcpu_res.start;
>  		vgic->can_emulate_gicv2 = true;
> -		kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
> -					KVM_DEV_TYPE_ARM_VGIC_V2);
> +		ret = kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
> +					      KVM_DEV_TYPE_ARM_VGIC_V2);
> +		if (ret)
> +			goto out;
>  	}
>  	if (vgic->vcpu_base == 0)
>  		kvm_info("disabling GICv2 emulation\n");
> -	kvm_register_device_ops(&kvm_arm_vgic_v3_ops, KVM_DEV_TYPE_ARM_VGIC_V3);
> +	ret = kvm_register_device_ops(&kvm_arm_vgic_v3_ops, KVM_DEV_TYPE_ARM_VGIC_V3);
> +	if (ret)
> +		goto out;
>  
>  	vgic->vctrl_base = NULL;
>  	vgic->type = VGIC_V3;
> 

This really should never happen.  Perhaps kvm_register_device_ops should
instead return void, and WARN() when it currently returns an error.

Paolo

[PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe

[nick]

On 2015-08-05 12:59 PM, Paolo Bonzini wrote:
> 
> 
> On 05/08/2015 18:48, Nicholas Krause wrote:
>> This fixes the error handling in the function vgic_v3_probe
>> for when calling the function kvm_register_device_ops to check
>> if the call to this function has returned a error code and if
>> so jump to the label out with goto to cleanup no longer required
>> resources used by the function vgic_v3_probe before returning the
>> error code from the call to kvm_register_device_ops to the caller
>> of the function vgic_v3_probe.
>>
>> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
>> ---
>>  virt/kvm/arm/vgic-v3.c | 10 +++++++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/virt/kvm/arm/vgic-v3.c b/virt/kvm/arm/vgic-v3.c
>> index dff0602..5102aa2 100644
>> --- a/virt/kvm/arm/vgic-v3.c
>> +++ b/virt/kvm/arm/vgic-v3.c
>> @@ -264,12 +264,16 @@ int vgic_v3_probe(struct device_node *vgic_node,
>>  	} else {
>>  		vgic->vcpu_base = vcpu_res.start;
>>  		vgic->can_emulate_gicv2 = true;
>> -		kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
>> -					KVM_DEV_TYPE_ARM_VGIC_V2);
>> +		ret = kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
>> +					      KVM_DEV_TYPE_ARM_VGIC_V2);
>> +		if (ret)
>> +			goto out;
>>  	}
>>  	if (vgic->vcpu_base == 0)
>>  		kvm_info("disabling GICv2 emulation\n");
>> -	kvm_register_device_ops(&kvm_arm_vgic_v3_ops, KVM_DEV_TYPE_ARM_VGIC_V3);
>> +	ret = kvm_register_device_ops(&kvm_arm_vgic_v3_ops, KVM_DEV_TYPE_ARM_VGIC_V3);
>> +	if (ret)
>> +		goto out;
>>  
>>  	vgic->vctrl_base = NULL;
>>  	vgic->type = VGIC_V3;
>>
> 
> This really should never happen.  Perhaps kvm_register_device_ops should
> instead return void, and WARN() when it currently returns an error.
> 
> Paolo
> 
Paolo,
I would like to do what you want but after tracing the callers of this function I found
this structure and wasn't sure if it can handle void function pointers.
static const struct of_device_id vgic_ids[] = {
        { .compatible = "arm,cortex-a15-gic",   .data = vgic_v2_probe, },
        { .compatible = "arm,cortex-a7-gic",    .data = vgic_v2_probe, },
        { .compatible = "arm,gic-400",          .data = vgic_v2_probe, },
        { .compatible = "arm,gic-v3",           .data = vgic_v3_probe, },
        {},
};
If this structure of function pointers can handle function pointers with a return type of 
void I will be glad to do what you request otherwise this would require a major rewrite
of kvm arm subsystem for a very simple bug fix.
Cheers,
Nick

[PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe

[Marc Zyngier]

On 05/08/15 18:07, nick wrote:
> 
> 
> On 2015-08-05 12:59 PM, Paolo Bonzini wrote:
>>
>>
>> On 05/08/2015 18:48, Nicholas Krause wrote:
>>> This fixes the error handling in the function vgic_v3_probe
>>> for when calling the function kvm_register_device_ops to check
>>> if the call to this function has returned a error code and if
>>> so jump to the label out with goto to cleanup no longer required
>>> resources used by the function vgic_v3_probe before returning the
>>> error code from the call to kvm_register_device_ops to the caller
>>> of the function vgic_v3_probe.
>>>
>>> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
>>> ---
>>>  virt/kvm/arm/vgic-v3.c | 10 +++++++---
>>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/virt/kvm/arm/vgic-v3.c b/virt/kvm/arm/vgic-v3.c
>>> index dff0602..5102aa2 100644
>>> --- a/virt/kvm/arm/vgic-v3.c
>>> +++ b/virt/kvm/arm/vgic-v3.c
>>> @@ -264,12 +264,16 @@ int vgic_v3_probe(struct device_node *vgic_node,
>>>  	} else {
>>>  		vgic->vcpu_base = vcpu_res.start;
>>>  		vgic->can_emulate_gicv2 = true;
>>> -		kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
>>> -					KVM_DEV_TYPE_ARM_VGIC_V2);
>>> +		ret = kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
>>> +					      KVM_DEV_TYPE_ARM_VGIC_V2);
>>> +		if (ret)
>>> +			goto out;
>>>  	}
>>>  	if (vgic->vcpu_base == 0)
>>>  		kvm_info("disabling GICv2 emulation\n");
>>> -	kvm_register_device_ops(&kvm_arm_vgic_v3_ops, KVM_DEV_TYPE_ARM_VGIC_V3);
>>> +	ret = kvm_register_device_ops(&kvm_arm_vgic_v3_ops, KVM_DEV_TYPE_ARM_VGIC_V3);
>>> +	if (ret)
>>> +		goto out;
>>>  
>>>  	vgic->vctrl_base = NULL;
>>>  	vgic->type = VGIC_V3;
>>>
>>
>> This really should never happen.  Perhaps kvm_register_device_ops should
>> instead return void, and WARN() when it currently returns an error.
>>
>> Paolo
>>
> Paolo,
> I would like to do what you want but after tracing the callers of this function I found
> this structure and wasn't sure if it can handle void function pointers.
> static const struct of_device_id vgic_ids[] = {
>         { .compatible = "arm,cortex-a15-gic",   .data = vgic_v2_probe, },
>         { .compatible = "arm,cortex-a7-gic",    .data = vgic_v2_probe, },
>         { .compatible = "arm,gic-400",          .data = vgic_v2_probe, },
>         { .compatible = "arm,gic-v3",           .data = vgic_v3_probe, },
>         {},
> };
> If this structure of function pointers can handle function pointers with a return type of 
> void I will be glad to do what you request otherwise this would require a major rewrite
> of kvm arm subsystem for a very simple bug fix.

Just like Paolo said, the error you report should never happen, and
would be caught by a WARN_ON() the first time anyone boots the kernel.
Also, failing to register the device ops results in not being able to
instantiate a VGIC. No harm done. I really don't understand why you want
to rewrite the probe functions.

There is plenty of things that could use a major rewrite in KVM/ARM, but
this is just not one of them.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe

[Paolo Bonzini]

On 06/08/2015 10:06, Marc Zyngier wrote:
> > If this structure of function pointers can handle function pointers with a return type of 
> > void I will be glad to do what you request otherwise this would require a major rewrite
> > of kvm arm subsystem for a very simple bug fix.
> 
> Just like Paolo said, the error you report should never happen, and
> would be caught by a WARN_ON() the first time anyone boots the kernel.
> Also, failing to register the device ops results in not being able to
> instantiate a VGIC. No harm done. I really don't understand why you want
> to rewrite the probe functions.

I think he just misunderstood my suggestion.  I didn't suggest making
the probe functions return void.  I suggested that
kvm_register_device_ops return void.

Paolo

[PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe

[Christoffer Dall]

On Thu, Aug 06, 2015 at 02:00:55PM +0200, Paolo Bonzini wrote:
> 
> 
> On 06/08/2015 10:06, Marc Zyngier wrote:
> > > If this structure of function pointers can handle function pointers with a return type of 
> > > void I will be glad to do what you request otherwise this would require a major rewrite
> > > of kvm arm subsystem for a very simple bug fix.
> > 
> > Just like Paolo said, the error you report should never happen, and
> > would be caught by a WARN_ON() the first time anyone boots the kernel.
> > Also, failing to register the device ops results in not being able to
> > instantiate a VGIC. No harm done. I really don't understand why you want
> > to rewrite the probe functions.
> 
> I think he just misunderstood my suggestion.  I didn't suggest making
> the probe functions return void.  I suggested that
> kvm_register_device_ops return void.
> 
s390 seems to actually deal with the return value of this function and
fail to init KVM at all if it fails, but on the other hand, this
function only fails if you're doing something truly stupid and
internal-to-kvm incoherent, so I think it's fair to just do a WARN_ON()
or even BUG_ON() and make the register function a void.

-Christoffer

[PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe

[nick]

On 2015-08-06 08:00 AM, Paolo Bonzini wrote:
> 
> 
> On 06/08/2015 10:06, Marc Zyngier wrote:
>>> If this structure of function pointers can handle function pointers with a return type of 
>>> void I will be glad to do what you request otherwise this would require a major rewrite
>>> of kvm arm subsystem for a very simple bug fix.
>>
>> Just like Paolo said, the error you report should never happen, and
>> would be caught by a WARN_ON() the first time anyone boots the kernel.
>> Also, failing to register the device ops results in not being able to
>> instantiate a VGIC. No harm done. I really don't understand why you want
>> to rewrite the probe functions.
> 
> I think he just misunderstood my suggestion.  I didn't suggest making
> the probe functions return void.  I suggested that
> kvm_register_device_ops return void.
> 
> Paolo
> 
Unfortunately the other maintainer is right in the s390 kvm subsystem uses the return value of the call to 
kvm_register_device_ops. However we could do something like a WARN_ON if kvm_register_device_ops fails in 
callers that never are required to never use it's return value.
Sorry about the Misunderstanding as I misread your suggestion.
Nick

[PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe

[Krzysztof Kozlowski]

2015-08-06 22:16 GMT+09:00 nick <xerofoify@gmail.com>:
>
>
> On 2015-08-06 08:00 AM, Paolo Bonzini wrote:
>>
>>
>> On 06/08/2015 10:06, Marc Zyngier wrote:
>>>> If this structure of function pointers can handle function pointers with a return type of
>>>> void I will be glad to do what you request otherwise this would require a major rewrite
>>>> of kvm arm subsystem for a very simple bug fix.
>>>
>>> Just like Paolo said, the error you report should never happen, and
>>> would be caught by a WARN_ON() the first time anyone boots the kernel.
>>> Also, failing to register the device ops results in not being able to
>>> instantiate a VGIC. No harm done. I really don't understand why you want
>>> to rewrite the probe functions.
>>
>> I think he just misunderstood my suggestion.  I didn't suggest making
>> the probe functions return void.  I suggested that
>> kvm_register_device_ops return void.
>>
>> Paolo
>>
> Unfortunately the other maintainer is right in the s390 kvm subsystem uses the return value of the call to
> kvm_register_device_ops. However we could do something like a WARN_ON if kvm_register_device_ops fails in
> callers that never are required to never use it's return value.
> Sorry about the Misunderstanding as I misread your suggestion.
> Nick

Dear Nick,

Since you are not testing the patches, please always mark them with
RFT prefix, instead of PATCH. Someone may get confused and actually
apply untested patch.

Best regards,
Krzysztof

[PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe

[nick]

On 2015-08-06 08:47 PM, Krzysztof Kozlowski wrote:
> 2015-08-06 22:16 GMT+09:00 nick <xerofoify@gmail.com>:
>>
>>
>> On 2015-08-06 08:00 AM, Paolo Bonzini wrote:
>>>
>>>
>>> On 06/08/2015 10:06, Marc Zyngier wrote:
>>>>> If this structure of function pointers can handle function pointers with a return type of
>>>>> void I will be glad to do what you request otherwise this would require a major rewrite
>>>>> of kvm arm subsystem for a very simple bug fix.
>>>>
>>>> Just like Paolo said, the error you report should never happen, and
>>>> would be caught by a WARN_ON() the first time anyone boots the kernel.
>>>> Also, failing to register the device ops results in not being able to
>>>> instantiate a VGIC. No harm done. I really don't understand why you want
>>>> to rewrite the probe functions.
>>>
>>> I think he just misunderstood my suggestion.  I didn't suggest making
>>> the probe functions return void.  I suggested that
>>> kvm_register_device_ops return void.
>>>
>>> Paolo
>>>
>> Unfortunately the other maintainer is right in the s390 kvm subsystem uses the return value of the call to
>> kvm_register_device_ops. However we could do something like a WARN_ON if kvm_register_device_ops fails in
>> callers that never are required to never use it's return value.
>> Sorry about the Misunderstanding as I misread your suggestion.
>> Nick
> 
> Dear Nick,
> 
> Since you are not testing the patches, please always mark them with
> RFT prefix, instead of PATCH. Someone may get confused and actually
> apply untested patch.
> 
> Best regards,
> Krzysztof
> 
Krzysztof,
I am not stating your wrong here but most of my patches are either trivial bug fixes that
don't need any testing or our on hardware I don't have lying around. In addition unless
my bugs are hard to trace a.k.a locking issues or hardware dependent that need proof due
to being unable to trace without the hardware I feel that your statement is a valid idea
but may not be the best here. If you would like me to still write RFT on my patches or
our concerned about me testing them I can assure you that there tested when I am able
to.
Cheers,
Nick 

[PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe

[Krzysztof Kozlowski]

On 07.08.2015 10:31, nick wrote:
> 
> 
> On 2015-08-06 08:47 PM, Krzysztof Kozlowski wrote:
>> 2015-08-06 22:16 GMT+09:00 nick <xerofoify@gmail.com>:
>>>
>>>
>>> On 2015-08-06 08:00 AM, Paolo Bonzini wrote:
>>>>
>>>>
>>>> On 06/08/2015 10:06, Marc Zyngier wrote:
>>>>>> If this structure of function pointers can handle function pointers with a return type of
>>>>>> void I will be glad to do what you request otherwise this would require a major rewrite
>>>>>> of kvm arm subsystem for a very simple bug fix.
>>>>>
>>>>> Just like Paolo said, the error you report should never happen, and
>>>>> would be caught by a WARN_ON() the first time anyone boots the kernel.
>>>>> Also, failing to register the device ops results in not being able to
>>>>> instantiate a VGIC. No harm done. I really don't understand why you want
>>>>> to rewrite the probe functions.
>>>>
>>>> I think he just misunderstood my suggestion.  I didn't suggest making
>>>> the probe functions return void.  I suggested that
>>>> kvm_register_device_ops return void.
>>>>
>>>> Paolo
>>>>
>>> Unfortunately the other maintainer is right in the s390 kvm subsystem uses the return value of the call to
>>> kvm_register_device_ops. However we could do something like a WARN_ON if kvm_register_device_ops fails in
>>> callers that never are required to never use it's return value.
>>> Sorry about the Misunderstanding as I misread your suggestion.
>>> Nick
>>
>> Dear Nick,
>>
>> Since you are not testing the patches, please always mark them with
>> RFT prefix, instead of PATCH. Someone may get confused and actually
>> apply untested patch.
>>
>> Best regards,
>> Krzysztof
>>
> Krzysztof,
> I am not stating your wrong here but most of my patches are either trivial bug fixes that
> don't need any testing or our on hardware I don't have lying around. In addition unless
> my bugs are hard to trace a.k.a locking issues or hardware dependent that need proof due
> to being unable to trace without the hardware I feel that your statement is a valid idea
> but may not be the best here. If you would like me to still write RFT on my patches or
> our concerned about me testing them I can assure you that there tested when I am able
> to.

Each patch, even trivial should be tested. If it is not tested then
please indicate it by putting a RFT tag. The maintainer may agree that
testing is not required. It's fine. However it is important to notify
the maintainer so he could make proper decision and assess the risk.

Contributor is not the right person to judge whether testing is
necessary or not.

*Please mark all your patches as RFT.*

I am also doing this on my patches that I cannot test.

Best regards,
Krzysztof

[PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe

[nick]

On 2015-08-06 09:36 PM, Krzysztof Kozlowski wrote:
> On 07.08.2015 10:31, nick wrote:
>>
>>
>> On 2015-08-06 08:47 PM, Krzysztof Kozlowski wrote:
>>> 2015-08-06 22:16 GMT+09:00 nick <xerofoify@gmail.com>:
>>>>
>>>>
>>>> On 2015-08-06 08:00 AM, Paolo Bonzini wrote:
>>>>>
>>>>>
>>>>> On 06/08/2015 10:06, Marc Zyngier wrote:
>>>>>>> If this structure of function pointers can handle function pointers with a return type of
>>>>>>> void I will be glad to do what you request otherwise this would require a major rewrite
>>>>>>> of kvm arm subsystem for a very simple bug fix.
>>>>>>
>>>>>> Just like Paolo said, the error you report should never happen, and
>>>>>> would be caught by a WARN_ON() the first time anyone boots the kernel.
>>>>>> Also, failing to register the device ops results in not being able to
>>>>>> instantiate a VGIC. No harm done. I really don't understand why you want
>>>>>> to rewrite the probe functions.
>>>>>
>>>>> I think he just misunderstood my suggestion.  I didn't suggest making
>>>>> the probe functions return void.  I suggested that
>>>>> kvm_register_device_ops return void.
>>>>>
>>>>> Paolo
>>>>>
>>>> Unfortunately the other maintainer is right in the s390 kvm subsystem uses the return value of the call to
>>>> kvm_register_device_ops. However we could do something like a WARN_ON if kvm_register_device_ops fails in
>>>> callers that never are required to never use it's return value.
>>>> Sorry about the Misunderstanding as I misread your suggestion.
>>>> Nick
>>>
>>> Dear Nick,
>>>
>>> Since you are not testing the patches, please always mark them with
>>> RFT prefix, instead of PATCH. Someone may get confused and actually
>>> apply untested patch.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>> Krzysztof,
>> I am not stating your wrong here but most of my patches are either trivial bug fixes that
>> don't need any testing or our on hardware I don't have lying around. In addition unless
>> my bugs are hard to trace a.k.a locking issues or hardware dependent that need proof due
>> to being unable to trace without the hardware I feel that your statement is a valid idea
>> but may not be the best here. If you would like me to still write RFT on my patches or
>> our concerned about me testing them I can assure you that there tested when I am able
>> to.
> 
> Each patch, even trivial should be tested. If it is not tested then
> please indicate it by putting a RFT tag. The maintainer may agree that
> testing is not required. It's fine. However it is important to notify
> the maintainer so he could make proper decision and assess the risk.
> 
> Contributor is not the right person to judge whether testing is
> necessary or not.
> 
> *Please mark all your patches as RFT.*
> 
> I am also doing this on my patches that I cannot test.
> 
> Best regards,
> Krzysztof
> 
Ok that's fine if that is the practice for untested patches I don't mind.
Nick