From: Paolo Bonzini <pbonzini@redhat.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Wanpeng Li <kernellwp@gmail.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
Sean Christopherson <sean.j.christopherson@intel.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
Naresh Kamboju <naresh.kamboju@linaro.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH] KVM: X86: Fix dereference null cpufreq policy
Date: Mon, 2 Mar 2020 11:23:30 +0100 [thread overview]
Message-ID: <9edb91b2-de08-bb54-f87a-7ac95eceebbc@redhat.com> (raw)
In-Reply-To: <20200302091416.od5ag3tokup4ha5m@vireshk-i7>
On 02/03/20 10:14, Viresh Kumar wrote:
>> For the same reason why we support kfree(NULL) and kobject_put(NULL)?
>
> These two helpers are used widely within kernel and many a times the
> resource is taken by one routine and dropped by another, and so
> someone needed to check if it can call the resource-free helper safely
> or not. IMO, that's not the case with cpufreq_cpu_put(). It is used
> mostly by the cpufreq core only and not too often by external
> entities. And even in that case we don't need to call
> cpufreq_cpu_put() from a different routine than the one which called
> cpufreq_cpu_get(). Like in your case. And so there is no need of an
> extra check to be made.
>
> I don't think we need to support cpufreq_cpu_put(NULL), but if Rafael
> wants it to be supported, I won't object to it.
Actually I think kobject_put is wrong in supporting NULL, because
documentation explicitly says to use container_of and not place kobj as
the first item. However, there is going to be some place in the kernel
that relies on it, so either removing the check or moving all kobjs to
the beginning of the struct is a windmill fight. I'll just apply
Wanpeng's patch.
Paolo
next prev parent reply other threads:[~2020-03-02 10:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-02 7:15 [PATCH] KVM: X86: Fix dereference null cpufreq policy Wanpeng Li
2020-03-02 7:55 ` Paolo Bonzini
2020-03-02 8:12 ` Viresh Kumar
2020-03-02 8:39 ` Paolo Bonzini
2020-03-02 9:14 ` Viresh Kumar
2020-03-02 10:23 ` Paolo Bonzini [this message]
2020-03-02 8:58 ` Naresh Kamboju
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9edb91b2-de08-bb54-f87a-7ac95eceebbc@redhat.com \
--to=pbonzini@redhat.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kernellwp@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=naresh.kamboju@linaro.org \
--cc=rjw@rjwysocki.net \
--cc=sean.j.christopherson@intel.com \
--cc=viresh.kumar@linaro.org \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).