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: <20190122184015.GC31777@kroah.com>
Date:   Tue, 22 Jan 2019 19:40:15 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     linux-kernel@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        kvm@...r.kernel.org
Subject: Re: [PATCH] kvm: no need to check return value of debugfs_create
 functions

On Tue, Jan 22, 2019 at 09:29:07AM -0800, Sean Christopherson wrote:
> On Tue, Jan 22, 2019 at 09:21:02AM -0800, Sean Christopherson wrote:
> > On Tue, Jan 22, 2019 at 04:21:50PM +0100, Greg Kroah-Hartman wrote:
> > > When calling debugfs functions, there is no need to ever check the
> > > return value.  The function can work or not, but the code logic should
> > > never do something different based on this.
> > 
> > What about wanting to make the debugfs all-or-nothing?  That seems like
> > a legitimate usage of checking the return value.
> > 
> > E.g. KVM removes the debugfs if kvm_arch_create_vcpu_debugfs() fails, and
> > the arch/x86/kvm/debugfs.c implementation of kvm_arch_create_vcpu_debugfs()
> > returns an error if any of its debugfs_create_file() calls fail.
> > 
> > If you're adamant about removing all debugfs create return value checks,
> > the aforementioned debugfs_create_file() calls should also be removed.
> > And at that point kvm_create_vcpu_debugfs() should have a 'void' return
> > value.
> 
> Belatedly saw the other series.  It'll require a bit more coordination,
> but folding this into the x86 series would allow for converting the KVM
> call stack to have 'void' returns.

Oh, nice, want me to tack this onto the end of there, or just do some
follow-on patches after this gets merged?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ