From: Pan Xinhui <xinhuix.pan@intel.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
"yanmin_zhang@linux.intel.com" <yanmin_zhang@linux.intel.com>,
"mnipxh@163.com" <mnipxh@163.com>
Subject: Re: [PATCH] acpi-cpufreq: Add a miss ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
Date: Tue, 14 Jul 2015 10:52:35 +0800 [thread overview]
Message-ID: <55A47973.5080900@intel.com> (raw)
In-Reply-To: <55A46F6B.6030006@intel.com>
hi, Rafael,
let me do more explanation :)
On 2015年07月14日 10:09, Pan Xinhui wrote:
> hi, Rafael,
> thanks for you reply :)
> On 2015年07月14日 07:26, Rafael J. Wysocki wrote:
>> On Monday, July 13, 2015 02:33:08 PM Pan Xinhui wrote:
>>> hi, Rafeal
>>> thanks for your reply. :)
>>>
>>> On 2015年07月11日 04:44, Rafael J. Wysocki wrote:
>>>> Hi,
>>>>
>>>> On Fri, Jul 10, 2015 at 7:50 AM, Pan Xinhui <xinhuix.pan@intel.com> wrote:
>>>>>
>>>>> If CONFIG_X86_ACPI_CPUFREQ_CPB has not been defined, the placeholder for
>>>>> cpb is not needed. Add ifdef around it.
>>>>>
>>>>> Signed-off-by: Pan Xinhui <xinhuix.pan@intel.com>
>>>>> ---
>>>>> drivers/cpufreq/acpi-cpufreq.c | 2 ++
>>>>> 1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
>>>>> index e7fcaa6..314a19e 100644
>>>>> --- a/drivers/cpufreq/acpi-cpufreq.c
>>>>> +++ b/drivers/cpufreq/acpi-cpufreq.c
>>>>> @@ -884,7 +884,9 @@ static int acpi_cpufreq_resume(struct cpufreq_policy *policy)
>>>>> static struct freq_attr *acpi_cpufreq_attr[] = {
>>>>> &cpufreq_freq_attr_scaling_available_freqs,
>>>>> &freqdomain_cpus,
>>>>> +#ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
>>>>> NULL, /* this is a placeholder for cpb, do not remove */
>>>>> +#endif
>>>>
>>>> Adding the ifdef here doesn't change anything, because the next NULL
>>>> will play the role of the one you've just #ifdefed and the structure
>>>> will be filled with zeros from that point on anyway.
>>>>
>>> Yes, adding ifdef here does not change any binary codes. But I want to make the codes more readable. :)
>>> Patch author has noticed two *NULL* here would confuse people, especially who first read this acpi-cpufreq.c file
>>> From code style point, it would be better to have #ifdef around it.
>>
>> Not really.
>>
>> Why don't you simply drop *both* NULLs?
>>
> Just like string end with *NULL* :)
>
> 1021 static int cpufreq_add_dev_interface(struct cpufreq_policy *policy,
> 1022 struct device *dev)
> 1023 {
> 1024 struct freq_attr **drv_attr;
> 1025 int ret = 0;
> 1026
> 1027 /* set up files for this cpu device */
> 1028 drv_attr = cpufreq_driver->attr;
> 1029 while (drv_attr && *drv_attr) {
> 1030 ret = sysfs_create_file(&policy->kobj, &((*drv_attr)->attr));
> 1031 if (ret)
> 1032 return ret;
> 1033 drv_attr++;
> 1034 }
> If struct freq_attr *acpi_cpufreq_attr[] did not end with NULL, line 1033 will access invalid data area.
> If *drv_attr(the data after struct freq_attr * array[]) happened to be not NULL. panic may hit in sysfs_create_file :(
> So at least one *NULL* must be in the end of freq_attr *array[].
>
> Actually in acpi-cpufreq.c, in acpi_cpufreq_init function.
> 957 struct freq_attr **iter;
> 958
> 959 pr_debug("adding sysfs entry for cpb\n");
> 960
> 961 for (iter = acpi_cpufreq_attr; *iter != NULL; iter++)
> 962 ;
> 963
> 964 /* make sure there is a terminator behind it */
> 965 if (iter[1] == NULL)
> 966 *iter = &cpb;
> 967 }
> line965, check of iter[1] is not needed. Maybe the patch author was afraid of an unexpected remove of first *NULL*.
> It might be a better solution to add ifdef CONFIG_X86_ACPI_CPUFREQ_CPB around that *NULL*, and remove this !iter[1] check.
>
According to line 961, the for loop, patch author assume the first *NULL* may be *at any index* of struct freq_attr *acpi_cpufreq_attr[].
But according to line 965, and the comment also says *a terminator behind it*. patch author assume the first *NULL* is *just right before* the second *NULL* which acts as a terminator.
The logic is incorrect. :(
Why not just
+ /* there must be two NULL in the end of acpi_cpufreq_attr[] */
+ struct freq_attr **iter = &acpi_cpufreq_attr[sizeof(acpi_cpufreq_attr) - 2];
+ if (!WARN_ON(iter[0] || iter[1]))
I don't like that codes assume the index of first *NULL*, so maybe removing line 965, the check if iter[1] == NULL, is more correct and beautiful :)
thanks
xinhui
> thanks
> xinhui
>
>>
>>>
>>>> You'd need to #ifdef it in the struct freq_attr definition, but I'm
>>>> not sure it's worth the effort.
>>>>
>>>
>>> struct freq_attr *cpb* is defined in #ifdef section. :)
>>
>> Ah, OK.
>>
>>
next prev parent reply other threads:[~2015-07-14 2:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-10 5:50 [PATCH] acpi-cpufreq: Add a miss ifdef CONFIG_X86_ACPI_CPUFREQ_CPB Pan Xinhui
2015-07-10 20:44 ` Rafael J. Wysocki
2015-07-13 6:33 ` Pan Xinhui
2015-07-13 6:33 ` Pan Xinhui
2015-07-13 23:26 ` Rafael J. Wysocki
2015-07-14 2:09 ` Pan Xinhui
2015-07-14 2:52 ` Pan Xinhui [this message]
2015-07-18 0:34 ` Rafael J. Wysocki
2015-07-20 5:14 ` Pan Xinhui
2015-07-20 21:47 ` Rafael J. Wysocki
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=55A47973.5080900@intel.com \
--to=xinhuix.pan@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mnipxh@163.com \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@linaro.org \
--cc=yanmin_zhang@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.