linux-kernel - Re: KVM: s390: Move two error code assignments in kvm_vm_ioctl_get_dirty

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

Message-ID: <75c6315c-8947-2816-64da-947f6a29ac57@users.sourceforge.net>
Date:   Tue, 24 Jan 2017 13:10:26 +0100
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Christian Bornträger <borntraeger@...ibm.com>,
        kvm@...r.kernel.org, linux-s390@...r.kernel.org
Cc:     Cornelia Huck <cornelia.huck@...ibm.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: KVM: s390: Move two error code assignments in
 kvm_vm_ioctl_get_dirty_log()

>> Would you like to check run time consequences
>> for the shown error code settings once more?
> 
> Sure, lets for now ignore the fact that the performance of an error path
> does not matter most of the time.

I am concerned that extra error code settings within the “success path”
could influence the run time behaviour in unwanted ways.


> After tree building and optimization your change should not matter at all
> regarding performance for a decent compiler.

I find your optimism interesting.


> The compiler can and will do much more complex transformations than this.

This technology is often fine.


> Since you have send several patches that trigger compile time warnings or
> errors, let me do this exercise for you and let us check what your patch
> changes in terms of run time consequences.
> 
> 
> $ git checkout v4.10-rc4
> HEAD is now at 49def18... Linux 4.10-rc4
> 
> $ make arch/s390/kvm/kvm-s390.o
> [..]


Thanks for your build demonstration.


> $ objdump -d arch/s390/kvm/kvm-s390.o | md5sum
> 55c1e081f55cef90b3ffcc06a13721c1  -
> 
> $ git am ~/code/elfring/[PATCH] KVM: s390: Move two error code assignments in kvm_vm_ioctl_get_dirty_log().eml
> Applying: KVM: s390: Move two error code assignments in kvm_vm_ioctl_get_dirty_log()
> 
> $ make arch/s390/kvm/kvm-s390.o
> [..]
> 
> $ objdump -d arch/s390/kvm/kvm-s390.o | md5sum
> 55c1e081f55cef90b3ffcc06a13721c1  -
> 
> As you can see the binary is identical,

The hashes became the same with the selected tool.


> so I can make an educated guess, that there is no performance improvement
> due to your patch.

How much does such a software generation result fit really to expectations?

Should the two shown implementation variants for a function like "kvm_vm_ioctl_get_dirty_log"
usually lead to different object code files?

Regards,
Markus