linux-kernel - Re: [PATCH 2/6] powerpc: kvm: no need to check return value of debugfs

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: <874kv5sp8s.fsf@mpe.ellerman.id.au>
Date:   Tue, 03 Mar 2020 21:32:19 +1100
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
        Paul Mackerras <paulus@...abs.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        kvm-ppc@...r.kernel.org
Subject: Re: [PATCH 2/6] powerpc: kvm: no need to check return value of debugfs_create functions

Greg Kroah-Hartman <gregkh@...uxfoundation.org> writes:
> On Tue, Mar 03, 2020 at 08:45:23PM +1100, Michael Ellerman wrote:
>> Greg Kroah-Hartman <gregkh@...uxfoundation.org> writes:
>> > On Tue, Mar 03, 2020 at 06:46:23PM +1100, Michael Ellerman wrote:
>> >> Greg Kroah-Hartman <gregkh@...uxfoundation.org> writes:
>> >> > 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.
>> >> 
>> >> Except it does need to do something different, if the file was created
>> >> it needs to be removed in the remove path.
>> >> 
>> >> > diff --git a/arch/powerpc/kvm/timing.c b/arch/powerpc/kvm/timing.c
>> >> > index bfe4f106cffc..8e4791c6f2af 100644
>> >> > --- a/arch/powerpc/kvm/timing.c
>> >> > +++ b/arch/powerpc/kvm/timing.c
>> >> > @@ -207,19 +207,12 @@ static const struct file_operations kvmppc_exit_timing_fops = {
>> >> >  void kvmppc_create_vcpu_debugfs(struct kvm_vcpu *vcpu, unsigned int id)
>> >> >  {
>> >> >  	static char dbg_fname[50];
>> >> > -	struct dentry *debugfs_file;
>> >> >  
>> >> >  	snprintf(dbg_fname, sizeof(dbg_fname), "vm%u_vcpu%u_timing",
>> >> >  		 current->pid, id);
>> >> > -	debugfs_file = debugfs_create_file(dbg_fname, 0666,
>> >> > -					kvm_debugfs_dir, vcpu,
>> >> > -					&kvmppc_exit_timing_fops);
>> >> > -
>> >> > -	if (!debugfs_file) {
>> >> > -		printk(KERN_ERR"%s: error creating debugfs file %s\n",
>> >> > -			__func__, dbg_fname);
>> >> > -		return;
>> >> > -	}
>> >> > +	debugfs_create_file(dbg_fname, 0666, kvm_debugfs_dir, vcpu,
>> >> > +			    &kvmppc_exit_timing_fops);
>> >> > +
>> >> >  
>> >> >  	vcpu->arch.debugfs_exit_timing = debugfs_file;
>> >
>> > Ugh, you are right, how did I miss that?  How is 0-day missing this?
>> > It's been in my tree for a long time, odd.
>> 
>> This code isn't enabled by default, or in any defconfig. So it's only
>> allmodconfig that would trip it, I guess 0-day isn't doing powerpc
>> allmodconfig builds.
>> 
>> >> I squashed this in, which seems to work:
>> ...
>> >>  
>> >>  void kvmppc_remove_vcpu_debugfs(struct kvm_vcpu *vcpu)
>> >>  {
>> >> -       if (vcpu->arch.debugfs_exit_timing) {
>> >> +       if (!IS_ERR_OR_NULL(vcpu->arch.debugfs_exit_timing)) {
>> >>                 debugfs_remove(vcpu->arch.debugfs_exit_timing);
>> >>                 vcpu->arch.debugfs_exit_timing = NULL;
>> >>         }
>> >
>> > No, this can just be:
>> > 	debugfs_remove(vcpu->arch.debugfs_exit_timing);
>> >
>> > No need to check anything, just call it and the debugfs code can handle
>> > it just fine.
>> 
>> Oh duh, of course, I should have checked.
>> 
>> I'd still like to NULL out the debugfs_exit_timing member, so I'll do:
>> 
>> void kvmppc_remove_vcpu_debugfs(struct kvm_vcpu *vcpu)
>> {
>> 	debugfs_remove(vcpu->arch.debugfs_exit_timing);
>> 	vcpu->arch.debugfs_exit_timing = NULL;
>> }
>
> Fair enough, but I doubt it ever matters :)

Yeah, but I'm paranoid and I have no way to test this code :)

> Thanks for the fixups, sorry for sending a broken patch, my fault.

No worries, we have too many CONFIG options.

cheers