linux-kernel - RE: [PATCH] x86/hyper-v: remove unnecessary conversions to bool

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] [day] [month] [year] [list]

Message-ID: <87tv4zpyni.fsf@vitty.brq.redhat.com>
Date:   Mon, 13 Jan 2020 09:07:45 +0100
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Michael Kelley <mikelley@...rosoft.com>,
        Chen Zhou <chenzhou10@...wei.com>
Cc:     "linux-hyperv\@vger.kernel.org" <linux-hyperv@...r.kernel.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        "chenzhou10\@huawei.com" <chenzhou10@...wei.com>,
        "tglx\@linutronix.de" <tglx@...utronix.de>,
        "mingo\@redhat.com" <mingo@...hat.com>
Subject: RE: [PATCH] x86/hyper-v: remove unnecessary conversions to bool

Michael Kelley <mikelley@...rosoft.com> writes:

> From: Vitaly Kuznetsov <vkuznets@...hat.com> Sent: Friday, January 10, 2020 4:00 AM
>> 
>> 
>> I'd suggest we get rid of bool functions completely instead, something
>> like (untested):
>
> Just curious:  Why prefer returning a u16 instead of a bool?  To avoid
> having to test 'ret' for zero in the return statements, or is there some
> broader reason?

Basically to preserve hypercall failure code and not hide it under 'false'.

>> -				     ipi_arg.cpu_mask);
>> -	return ((ret == 0) ? true : false);
>> +	return (u16)hv_do_fast_hypercall16(HVCALL_SEND_IPI, ipi_arg.vector,
>> +					   ipi_arg.cpu_mask);
>
> The cast to u16 seems a bit dangerous. The hypercall status code is indeed
> returned in the low 16 bits of the hypercall result value, so it works, and
> maybe that is why you suggested u16 as the function return value.  But it
> is a non-obvious assumption.  

This is not obvious, I agree, and we can create a wrapper for it but we
more or less must convert it to 'u16': uppper bits don't indicate a
failure (e.g. 'reps complete').

-- 
Vitaly