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 for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAJKOXPeVGmrkBwRRY6D46MhXtWH+_ybxyJpQjyH4F7BOpKLxSQ@mail.gmail.com>
Date:	Fri, 7 Aug 2015 09:47:46 +0900
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	nick <xerofoify@...il.com>
Cc:	Paolo Bonzini <pbonzini@...hat.com>,
	Marc Zyngier <marc.zyngier@....com>,
	"christoffer.dall@...aro.org" <christoffer.dall@...aro.org>,
	"gleb@...nel.org" <gleb@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kvmarm@...ts.cs.columbia.edu" <kvmarm@...ts.cs.columbia.edu>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH] kvm:arm:Fix error handling in the function vgic_v3_probe

2015-08-06 22:16 GMT+09:00 nick <xerofoify@...il.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
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ