From: nick <xerofoify@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Marc Zyngier <marc.zyngier@arm.com>,
"christoffer.dall@linaro.org" <christoffer.dall@linaro.org>
Cc: "gleb@kernel.org" <gleb@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe
Date: Thu, 06 Aug 2015 09:16:45 -0400 [thread overview]
Message-ID: <55C35E3D.9000708@gmail.com> (raw)
In-Reply-To: <55C34C77.7090303@redhat.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
WARNING: multiple messages have this Message-ID (diff)
From: xerofoify@gmail.com (nick)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe
Date: Thu, 06 Aug 2015 09:16:45 -0400 [thread overview]
Message-ID: <55C35E3D.9000708@gmail.com> (raw)
In-Reply-To: <55C34C77.7090303@redhat.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
next prev parent reply other threads:[~2015-08-06 13:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-05 16:48 [PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe Nicholas Krause
2015-08-05 16:48 ` Nicholas Krause
2015-08-05 16:59 ` Paolo Bonzini
2015-08-05 16:59 ` Paolo Bonzini
2015-08-05 17:07 ` nick
2015-08-05 17:07 ` nick
2015-08-06 8:06 ` Marc Zyngier
2015-08-06 8:06 ` Marc Zyngier
2015-08-06 12:00 ` Paolo Bonzini
2015-08-06 12:00 ` Paolo Bonzini
2015-08-06 12:08 ` Christoffer Dall
2015-08-06 12:08 ` Christoffer Dall
2015-08-06 12:08 ` Christoffer Dall
2015-08-06 13:16 ` nick [this message]
2015-08-06 13:16 ` nick
2015-08-07 0:47 ` Krzysztof Kozlowski
2015-08-07 0:47 ` Krzysztof Kozlowski
2015-08-07 1:31 ` nick
2015-08-07 1:31 ` nick
2015-08-07 1:36 ` Krzysztof Kozlowski
2015-08-07 1:36 ` Krzysztof Kozlowski
2015-08-07 1:40 ` nick
2015-08-07 1:40 ` nick
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=55C35E3D.9000708@gmail.com \
--to=xerofoify@gmail.com \
--cc=christoffer.dall@linaro.org \
--cc=gleb@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=pbonzini@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.