linux-kernel - Re: xen_exit

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

Date:   Thu, 27 Apr 2017 08:27:31 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        Juergen Gross <jgross@...e.com>, X86 ML <x86@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: xen_exit_mmap() questions

* Boris Ostrovsky <boris.ostrovsky@...cle.com> wrote:

> > xen_mc_issue() does:
> > 
> >         if ((paravirt_get_lazy_mode() & mode) == 0)
> >                 xen_mc_flush();
> > 
> > I assume the load_cr3() is intended to deal with the case where we're
> > in lazy mode, but we'll still be in lazy mode, right?  Or does it
> > serve some other purpose?
> 
> Of course. I can't read (I ignored the "== 0" part).

Ha, ob'sidenote: the preferred form to write this is:

	if (!(paravirt_get_lazy_mode() & mode))
		xen_mc_flush();

... exactly due to the readability problem you ran into: a 'pre' negation is much 
easier to read, plus '==' tends to trigger 'equal to' attributes in the brain, 
which is the opposite of negation. So it's very easy to mis-read such syntactic 
constructs even if they are technically correct.

I think '== 0' should be forbidden in all cases where the purpose is a logic 
operation and should be used strictly only in cases where we do explicit integer 
arithmetics.

(Bools and '== false' are suboptimal for similar reasons.)

... but I digress!

	Ingo