* [PATCH v4 1/2] cpufreq: fix race on cpufreq online
@ 2022-05-12 13:52 Schspa Shi
2022-05-12 13:52 ` [PATCH v4 2/2] cpufreq: make interface functions and lock holding state clear Schspa Shi
2022-05-13 4:18 ` [PATCH v4 1/2] cpufreq: fix race on cpufreq online Viresh Kumar
0 siblings, 2 replies; 11+ messages in thread
From: Schspa Shi @ 2022-05-12 13:52 UTC (permalink / raw)
To: rafael, viresh.kumar; +Cc: linux-pm, linux-kernel, schspa
When cpufreq online failed, policy->cpus are not empty while
cpufreq sysfs file available, we may access some data freed.
Take policy->clk as an example:
static int cpufreq_online(unsigned int cpu)
{
...
// policy->cpus != 0 at this time
down_write(&policy->rwsem);
ret = cpufreq_add_dev_interface(policy);
up_write(&policy->rwsem);
down_write(&policy->rwsem);
...
/* cpufreq nitialization fails in some cases */
if (cpufreq_driver->get && has_target()) {
policy->cur = cpufreq_driver->get(policy->cpu);
if (!policy->cur) {
ret = -EIO;
pr_err("%s: ->get() failed\n", __func__);
goto out_destroy_policy;
}
}
...
up_write(&policy->rwsem);
...
return 0;
out_destroy_policy:
for_each_cpu(j, policy->real_cpus)
remove_cpu_dev_symlink(policy, get_cpu_device(j));
up_write(&policy->rwsem);
...
out_exit_policy:
if (cpufreq_driver->exit)
cpufreq_driver->exit(policy);
clk_put(policy->clk);
// policy->clk is a wild pointer
...
^
|
Another process access
__cpufreq_get
cpufreq_verify_current_freq
cpufreq_generic_get
// acces wild pointer of policy->clk;
|
|
out_offline_policy: |
cpufreq_policy_free(policy); |
// deleted here, and will wait for no body reference
cpufreq_policy_put_kobj(policy);
}
We can fix it by clear the policy->cpus mask.
Both show_scaling_cur_freq and show_cpuinfo_cur_freq will return an
error by checking this mask, thus avoiding UAF.
Signed-off-by: Schspa Shi <schspa@gmail.com>
---
Changelog:
v1 -> v2:
- Fix bad critical region enlarge which causes uninitialized
unlock.
- Move cpumask_clear(policy->cpus); before out_offline_policy
v2 -> v3:
- Remove the missed down_write() before
cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);
v3 -> v4:
- Seprate to two patchs.
- Add policy_is_inactive check before sysfs access
---
drivers/cpufreq/cpufreq.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 80f535cc8a75..35dffd738580 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -953,7 +953,10 @@ static ssize_t show(struct kobject *kobj, struct attribute *attr, char *buf)
return -EIO;
down_read(&policy->rwsem);
- ret = fattr->show(policy, buf);
+ if (unlikely(policy_is_inactive(policy)))
+ ret = -EBUSY;
+ else
+ ret = fattr->show(policy, buf);
up_read(&policy->rwsem);
return ret;
@@ -978,7 +981,10 @@ static ssize_t store(struct kobject *kobj, struct attribute *attr,
if (cpu_online(policy->cpu)) {
down_write(&policy->rwsem);
- ret = fattr->store(policy, buf, count);
+ if (unlikely(policy_is_inactive(policy)))
+ ret = -EBUSY;
+ else
+ ret = fattr->store(policy, buf, count);
up_write(&policy->rwsem);
}
@@ -1533,6 +1539,7 @@ static int cpufreq_online(unsigned int cpu)
for_each_cpu(j, policy->real_cpus)
remove_cpu_dev_symlink(policy, get_cpu_device(j));
+ cpumask_clear(policy->cpus);
up_write(&policy->rwsem);
out_offline_policy:
--
2.29.0
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH v4 2/2] cpufreq: make interface functions and lock holding state clear
2022-05-12 13:52 [PATCH v4 1/2] cpufreq: fix race on cpufreq online Schspa Shi
@ 2022-05-12 13:52 ` Schspa Shi
2022-05-12 14:44 ` Rafael J. Wysocki
` (2 more replies)
2022-05-13 4:18 ` [PATCH v4 1/2] cpufreq: fix race on cpufreq online Viresh Kumar
1 sibling, 3 replies; 11+ messages in thread
From: Schspa Shi @ 2022-05-12 13:52 UTC (permalink / raw)
To: rafael, viresh.kumar; +Cc: linux-pm, linux-kernel, schspa
cpufreq_offline() calls offline() and exit() under the policy rwsem
But they are called outside the rwsem in cpufreq_online().
This patch move the offline(), exit(), online(), init() to be inside
of policy rwsem to achieve a clear lock relationship.
All the init() online() implement only initialize policy object without
holding this lock and won't call cpufreq APIs need to hold this lock.
Signed-off-by: Schspa Shi <schspa@gmail.com>
---
drivers/cpufreq/cpufreq.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 35dffd738580..f242d5488364 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1343,12 +1343,12 @@ static int cpufreq_online(unsigned int cpu)
down_write(&policy->rwsem);
policy->cpu = cpu;
policy->governor = NULL;
- up_write(&policy->rwsem);
} else {
new_policy = true;
policy = cpufreq_policy_alloc(cpu);
if (!policy)
return -ENOMEM;
+ down_write(&policy->rwsem);
}
if (!new_policy && cpufreq_driver->online) {
@@ -1388,7 +1388,6 @@ static int cpufreq_online(unsigned int cpu)
cpumask_copy(policy->related_cpus, policy->cpus);
}
- down_write(&policy->rwsem);
/*
* affected cpus must always be the one, which are online. We aren't
* managing offline cpus here.
@@ -1540,7 +1539,6 @@ static int cpufreq_online(unsigned int cpu)
remove_cpu_dev_symlink(policy, get_cpu_device(j));
cpumask_clear(policy->cpus);
- up_write(&policy->rwsem);
out_offline_policy:
if (cpufreq_driver->offline)
@@ -1549,6 +1547,7 @@ static int cpufreq_online(unsigned int cpu)
out_exit_policy:
if (cpufreq_driver->exit)
cpufreq_driver->exit(policy);
+ up_write(&policy->rwsem);
out_free_policy:
cpufreq_policy_free(policy);
--
2.29.0
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v4 2/2] cpufreq: make interface functions and lock holding state clear
2022-05-12 13:52 ` [PATCH v4 2/2] cpufreq: make interface functions and lock holding state clear Schspa Shi
@ 2022-05-12 14:44 ` Rafael J. Wysocki
2022-05-12 16:01 ` Schspa Shi
2022-05-13 4:29 ` Viresh Kumar
[not found] ` <20220515095313.GE10578@xsang-OptiPlex-9020>
2 siblings, 1 reply; 11+ messages in thread
From: Rafael J. Wysocki @ 2022-05-12 14:44 UTC (permalink / raw)
To: Schspa Shi
Cc: Rafael J. Wysocki, Viresh Kumar, Linux PM,
Linux Kernel Mailing List
On Thu, May 12, 2022 at 3:52 PM Schspa Shi <schspa@gmail.com> wrote:
>
> cpufreq_offline() calls offline() and exit() under the policy rwsem
> But they are called outside the rwsem in cpufreq_online().
>
> This patch move the offline(), exit(), online(), init() to be inside
> of policy rwsem to achieve a clear lock relationship.
>
> All the init() online() implement only initialize policy object without
> holding this lock and won't call cpufreq APIs need to hold this lock.
>
> Signed-off-by: Schspa Shi <schspa@gmail.com>
IMV this still addresses 2 different issues and so it should be split
into 2 different patches.
> ---
> drivers/cpufreq/cpufreq.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 35dffd738580..f242d5488364 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
Patch 1:
> @@ -1343,12 +1343,12 @@ static int cpufreq_online(unsigned int cpu)
> down_write(&policy->rwsem);
> policy->cpu = cpu;
> policy->governor = NULL;
> - up_write(&policy->rwsem);
> } else {
> new_policy = true;
> policy = cpufreq_policy_alloc(cpu);
> if (!policy)
> return -ENOMEM;
> + down_write(&policy->rwsem);
> }
>
> if (!new_policy && cpufreq_driver->online) {
> @@ -1388,7 +1388,6 @@ static int cpufreq_online(unsigned int cpu)
> cpumask_copy(policy->related_cpus, policy->cpus);
> }
>
> - down_write(&policy->rwsem);
> /*
> * affected cpus must always be the one, which are online. We aren't
> * managing offline cpus here.
which addresses the problem that cpufreq_online() updates the
policy->cpus and related_cpus masks without holding the policy rwsem
(since the policy kobject has been registered already at this point,
this is generally unsafe).
A side-effect of it is that ->online() and ->init() will be called
under the policy rwsem now, but that should be fine and is more
consistent than the current code too.
Patch 2:
> @@ -1540,7 +1539,6 @@ static int cpufreq_online(unsigned int cpu)
> remove_cpu_dev_symlink(policy, get_cpu_device(j));
>
> cpumask_clear(policy->cpus);
> - up_write(&policy->rwsem);
>
> out_offline_policy:
> if (cpufreq_driver->offline)
> @@ -1549,6 +1547,7 @@ static int cpufreq_online(unsigned int cpu)
> out_exit_policy:
> if (cpufreq_driver->exit)
> cpufreq_driver->exit(policy);
> + up_write(&policy->rwsem);
>
> out_free_policy:
> cpufreq_policy_free(policy);
> --
which addressed the issue of calling ->offline() and ->exit() without
holding the policy rwsem that is at best inconsistent with
cpufreq_offline().
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 2/2] cpufreq: make interface functions and lock holding state clear
2022-05-12 14:44 ` Rafael J. Wysocki
@ 2022-05-12 16:01 ` Schspa Shi
2022-05-12 16:23 ` Rafael J. Wysocki
0 siblings, 1 reply; 11+ messages in thread
From: Schspa Shi @ 2022-05-12 16:01 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Viresh Kumar, Linux PM, Linux Kernel Mailing List
"Rafael J. Wysocki" <rafael@kernel.org> writes:
> On Thu, May 12, 2022 at 3:52 PM Schspa Shi <schspa@gmail.com> wrote:
>>
>> cpufreq_offline() calls offline() and exit() under the policy rwsem
>> But they are called outside the rwsem in cpufreq_online().
>>
>> This patch move the offline(), exit(), online(), init() to be inside
>> of policy rwsem to achieve a clear lock relationship.
>>
>> All the init() online() implement only initialize policy object without
>> holding this lock and won't call cpufreq APIs need to hold this lock.
>>
>> Signed-off-by: Schspa Shi <schspa@gmail.com>
>
> IMV this still addresses 2 different issues and so it should be split
> into 2 different patches.
>
>> ---
>> drivers/cpufreq/cpufreq.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 35dffd738580..f242d5488364 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>
> Patch 1:
>
>> @@ -1343,12 +1343,12 @@ static int cpufreq_online(unsigned int cpu)
>> down_write(&policy->rwsem);
>> policy->cpu = cpu;
>> policy->governor = NULL;
>> - up_write(&policy->rwsem);
>> } else {
>> new_policy = true;
>> policy = cpufreq_policy_alloc(cpu);
>> if (!policy)
>> return -ENOMEM;
>> + down_write(&policy->rwsem);
>> }
>>
>> if (!new_policy && cpufreq_driver->online) {
>> @@ -1388,7 +1388,6 @@ static int cpufreq_online(unsigned int cpu)
>> cpumask_copy(policy->related_cpus, policy->cpus);
>> }
>>
>> - down_write(&policy->rwsem);
>> /*
>> * affected cpus must always be the one, which are online. We aren't
>> * managing offline cpus here.
>
> which addresses the problem that cpufreq_online() updates the
> policy->cpus and related_cpus masks without holding the policy rwsem
> (since the policy kobject has been registered already at this point,
> this is generally unsafe).
>
> A side-effect of it is that ->online() and ->init() will be called
> under the policy rwsem now, but that should be fine and is more
> consistent than the current code too.
>
> Patch 2:
>
>> @@ -1540,7 +1539,6 @@ static int cpufreq_online(unsigned int cpu)
>> remove_cpu_dev_symlink(policy, get_cpu_device(j));
>>
>> cpumask_clear(policy->cpus);
>> - up_write(&policy->rwsem);
>>
>> out_offline_policy:
>> if (cpufreq_driver->offline)
>> @@ -1549,6 +1547,7 @@ static int cpufreq_online(unsigned int cpu)
>> out_exit_policy:
>> if (cpufreq_driver->exit)
>> cpufreq_driver->exit(policy);
>> + up_write(&policy->rwsem);
>>
>> out_free_policy:
>> cpufreq_policy_free(policy);
>> --
>
> which addressed the issue of calling ->offline() and ->exit() without
> holding the policy rwsem that is at best inconsistent with
> cpufreq_offline().
No, we can't split this into two different patches. which will cause a
uninitialized unlock for policy rwsem.
This will make the git bitsec unusable.
Which Dan Carpenter reported, and cause the patch of the v1 version to
be reverted.
Link: https://lore.kernel.org/all/YnKZCGaig+EXSowf@kili/
---
BRs
Schspa Shi
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 2/2] cpufreq: make interface functions and lock holding state clear
2022-05-12 16:01 ` Schspa Shi
@ 2022-05-12 16:23 ` Rafael J. Wysocki
0 siblings, 0 replies; 11+ messages in thread
From: Rafael J. Wysocki @ 2022-05-12 16:23 UTC (permalink / raw)
To: Schspa Shi
Cc: Rafael J. Wysocki, Viresh Kumar, Linux PM,
Linux Kernel Mailing List
On Thu, May 12, 2022 at 6:01 PM Schspa Shi <schspa@gmail.com> wrote:
>
> "Rafael J. Wysocki" <rafael@kernel.org> writes:
>
> > On Thu, May 12, 2022 at 3:52 PM Schspa Shi <schspa@gmail.com> wrote:
> >>
> >> cpufreq_offline() calls offline() and exit() under the policy rwsem
> >> But they are called outside the rwsem in cpufreq_online().
> >>
> >> This patch move the offline(), exit(), online(), init() to be inside
> >> of policy rwsem to achieve a clear lock relationship.
> >>
> >> All the init() online() implement only initialize policy object without
> >> holding this lock and won't call cpufreq APIs need to hold this lock.
> >>
> >> Signed-off-by: Schspa Shi <schspa@gmail.com>
> >
> > IMV this still addresses 2 different issues and so it should be split
> > into 2 different patches.
> >
> >> ---
> >> drivers/cpufreq/cpufreq.c | 5 ++---
> >> 1 file changed, 2 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> >> index 35dffd738580..f242d5488364 100644
> >> --- a/drivers/cpufreq/cpufreq.c
> >> +++ b/drivers/cpufreq/cpufreq.c
> >
> > Patch 1:
> >
> >> @@ -1343,12 +1343,12 @@ static int cpufreq_online(unsigned int cpu)
> >> down_write(&policy->rwsem);
> >> policy->cpu = cpu;
> >> policy->governor = NULL;
> >> - up_write(&policy->rwsem);
> >> } else {
> >> new_policy = true;
> >> policy = cpufreq_policy_alloc(cpu);
> >> if (!policy)
> >> return -ENOMEM;
> >> + down_write(&policy->rwsem);
> >> }
> >>
> >> if (!new_policy && cpufreq_driver->online) {
> >> @@ -1388,7 +1388,6 @@ static int cpufreq_online(unsigned int cpu)
> >> cpumask_copy(policy->related_cpus, policy->cpus);
> >> }
> >>
> >> - down_write(&policy->rwsem);
> >> /*
> >> * affected cpus must always be the one, which are online. We aren't
> >> * managing offline cpus here.
> >
> > which addresses the problem that cpufreq_online() updates the
> > policy->cpus and related_cpus masks without holding the policy rwsem
> > (since the policy kobject has been registered already at this point,
> > this is generally unsafe).
> >
> > A side-effect of it is that ->online() and ->init() will be called
> > under the policy rwsem now, but that should be fine and is more
> > consistent than the current code too.
> >
> > Patch 2:
> >
> >> @@ -1540,7 +1539,6 @@ static int cpufreq_online(unsigned int cpu)
> >> remove_cpu_dev_symlink(policy, get_cpu_device(j));
> >>
> >> cpumask_clear(policy->cpus);
> >> - up_write(&policy->rwsem);
> >>
> >> out_offline_policy:
> >> if (cpufreq_driver->offline)
> >> @@ -1549,6 +1547,7 @@ static int cpufreq_online(unsigned int cpu)
> >> out_exit_policy:
> >> if (cpufreq_driver->exit)
> >> cpufreq_driver->exit(policy);
> >> + up_write(&policy->rwsem);
> >>
> >> out_free_policy:
> >> cpufreq_policy_free(policy);
> >> --
> >
> > which addressed the issue of calling ->offline() and ->exit() without
> > holding the policy rwsem that is at best inconsistent with
> > cpufreq_offline().
>
> No, we can't split this into two different patches. which will cause a
> uninitialized unlock for policy rwsem.
> This will make the git bitsec unusable.
>
> Which Dan Carpenter reported, and cause the patch of the v1 version to
> be reverted.
>
> Link: https://lore.kernel.org/all/YnKZCGaig+EXSowf@kili/
Ah, OK. Never mind.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/2] cpufreq: fix race on cpufreq online
2022-05-12 13:52 [PATCH v4 1/2] cpufreq: fix race on cpufreq online Schspa Shi
2022-05-12 13:52 ` [PATCH v4 2/2] cpufreq: make interface functions and lock holding state clear Schspa Shi
@ 2022-05-13 4:18 ` Viresh Kumar
2022-05-13 6:06 ` Schspa Shi
1 sibling, 1 reply; 11+ messages in thread
From: Viresh Kumar @ 2022-05-13 4:18 UTC (permalink / raw)
To: Schspa Shi; +Cc: rafael, linux-pm, linux-kernel
On 12-05-22, 21:52, Schspa Shi wrote:
> When cpufreq online failed, policy->cpus are not empty while
> cpufreq sysfs file available, we may access some data freed.
>
> Take policy->clk as an example:
>
> static int cpufreq_online(unsigned int cpu)
> {
> ...
> // policy->cpus != 0 at this time
> down_write(&policy->rwsem);
> ret = cpufreq_add_dev_interface(policy);
> up_write(&policy->rwsem);
>
> down_write(&policy->rwsem);
> ...
> /* cpufreq nitialization fails in some cases */
> if (cpufreq_driver->get && has_target()) {
> policy->cur = cpufreq_driver->get(policy->cpu);
> if (!policy->cur) {
> ret = -EIO;
> pr_err("%s: ->get() failed\n", __func__);
> goto out_destroy_policy;
> }
> }
> ...
> up_write(&policy->rwsem);
> ...
>
> return 0;
>
> out_destroy_policy:
> for_each_cpu(j, policy->real_cpus)
> remove_cpu_dev_symlink(policy, get_cpu_device(j));
> up_write(&policy->rwsem);
> ...
> out_exit_policy:
> if (cpufreq_driver->exit)
> cpufreq_driver->exit(policy);
> clk_put(policy->clk);
> // policy->clk is a wild pointer
> ...
> ^
> |
> Another process access
> __cpufreq_get
> cpufreq_verify_current_freq
> cpufreq_generic_get
> // acces wild pointer of policy->clk;
> |
> |
> out_offline_policy: |
> cpufreq_policy_free(policy); |
> // deleted here, and will wait for no body reference
> cpufreq_policy_put_kobj(policy);
> }
> We can fix it by clear the policy->cpus mask.
> Both show_scaling_cur_freq and show_cpuinfo_cur_freq will return an
> error by checking this mask, thus avoiding UAF.
Instead of all above, what about this.
Subject: Abort show/store for half initialized policy
If policy initialization fails after the sysfs files are created,
there is a possibility that we may end up running show()/store()
callbacks for half initialized policies, which may have unpredictable
outcomes.
Abort show/store in such a case by making sure the policy is active.
Also inactivate the policy on such failures.
> Signed-off-by: Schspa Shi <schspa@gmail.com>
>
> ---
>
> Changelog:
> v1 -> v2:
> - Fix bad critical region enlarge which causes uninitialized
> unlock.
> - Move cpumask_clear(policy->cpus); before out_offline_policy
> v2 -> v3:
> - Remove the missed down_write() before
> cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);
> v3 -> v4:
> - Seprate to two patchs.
> - Add policy_is_inactive check before sysfs access
> ---
> drivers/cpufreq/cpufreq.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 80f535cc8a75..35dffd738580 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -953,7 +953,10 @@ static ssize_t show(struct kobject *kobj, struct attribute *attr, char *buf)
> return -EIO;
>
> down_read(&policy->rwsem);
> - ret = fattr->show(policy, buf);
> + if (unlikely(policy_is_inactive(policy)))
> + ret = -EBUSY;
> + else
> + ret = fattr->show(policy, buf);
I like it the way I have done earlier, initialize ret to -EBUSY and
get rid of the else part and call show/store in if itself. Same for
below.
> up_read(&policy->rwsem);
>
> return ret;
> @@ -978,7 +981,10 @@ static ssize_t store(struct kobject *kobj, struct attribute *attr,
>
> if (cpu_online(policy->cpu)) {
> down_write(&policy->rwsem);
> - ret = fattr->store(policy, buf, count);
> + if (unlikely(policy_is_inactive(policy)))
> + ret = -EBUSY;
> + else
> + ret = fattr->store(policy, buf, count);
> up_write(&policy->rwsem);
> }
>
> @@ -1533,6 +1539,7 @@ static int cpufreq_online(unsigned int cpu)
> for_each_cpu(j, policy->real_cpus)
> remove_cpu_dev_symlink(policy, get_cpu_device(j));
>
> + cpumask_clear(policy->cpus);
> up_write(&policy->rwsem);
>
> out_offline_policy:
> --
> 2.29.0
--
viresh
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 2/2] cpufreq: make interface functions and lock holding state clear
2022-05-12 13:52 ` [PATCH v4 2/2] cpufreq: make interface functions and lock holding state clear Schspa Shi
2022-05-12 14:44 ` Rafael J. Wysocki
@ 2022-05-13 4:29 ` Viresh Kumar
[not found] ` <20220515095313.GE10578@xsang-OptiPlex-9020>
2 siblings, 0 replies; 11+ messages in thread
From: Viresh Kumar @ 2022-05-13 4:29 UTC (permalink / raw)
To: Schspa Shi; +Cc: rafael, linux-pm, linux-kernel
On 12-05-22, 21:52, Schspa Shi wrote:
> cpufreq_offline() calls offline() and exit() under the policy rwsem
> But they are called outside the rwsem in cpufreq_online().
>
> This patch move the offline(), exit(), online(), init() to be inside
> of policy rwsem to achieve a clear lock relationship.
>
> All the init() online() implement only initialize policy object without
> holding this lock and won't call cpufreq APIs need to hold this lock.
>
> Signed-off-by: Schspa Shi <schspa@gmail.com>
> ---
> drivers/cpufreq/cpufreq.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/2] cpufreq: fix race on cpufreq online
2022-05-13 4:18 ` [PATCH v4 1/2] cpufreq: fix race on cpufreq online Viresh Kumar
@ 2022-05-13 6:06 ` Schspa Shi
2022-05-13 6:13 ` Viresh Kumar
0 siblings, 1 reply; 11+ messages in thread
From: Schspa Shi @ 2022-05-13 6:06 UTC (permalink / raw)
To: Viresh Kumar; +Cc: Rafael J. Wysocki, Linux PM, Linux Kernel Mailing List
Viresh Kumar <viresh.kumar@linaro.org> writes:
> On 12-05-22, 21:52, Schspa Shi wrote:
>> When cpufreq online failed, policy->cpus are not empty while
>> cpufreq sysfs file available, we may access some data freed.
>>
>> Take policy->clk as an example:
>>
>> static int cpufreq_online(unsigned int cpu)
>> {
>> ...
>> // policy->cpus != 0 at this time
>> down_write(&policy->rwsem);
>> ret = cpufreq_add_dev_interface(policy);
>> up_write(&policy->rwsem);
>>
>> down_write(&policy->rwsem);
>> ...
>> /* cpufreq nitialization fails in some cases */
>> if (cpufreq_driver->get && has_target()) {
>> policy->cur = cpufreq_driver->get(policy->cpu);
>> if (!policy->cur) {
>> ret = -EIO;
>> pr_err("%s: ->get() failed\n", __func__);
>> goto out_destroy_policy;
>> }
>> }
>> ...
>> up_write(&policy->rwsem);
>> ...
>>
>> return 0;
>>
>> out_destroy_policy:
>> for_each_cpu(j, policy->real_cpus)
>> remove_cpu_dev_symlink(policy, get_cpu_device(j));
>> up_write(&policy->rwsem);
>> ...
>> out_exit_policy:
>> if (cpufreq_driver->exit)
>> cpufreq_driver->exit(policy);
>> clk_put(policy->clk);
>> // policy->clk is a wild pointer
>> ...
>> ^
>> |
>> Another process access
>> __cpufreq_get
>> cpufreq_verify_current_freq
>> cpufreq_generic_get
>> // acces wild pointer of policy->clk;
>> |
>> |
>> out_offline_policy: |
>> cpufreq_policy_free(policy); |
>> // deleted here, and will wait for no body reference
>> cpufreq_policy_put_kobj(policy);
>> }
>> We can fix it by clear the policy->cpus mask.
>> Both show_scaling_cur_freq and show_cpuinfo_cur_freq will return an
>> error by checking this mask, thus avoiding UAF.
>
> Instead of all above, what about this.
>
> Subject: Abort show/store for half initialized policy
>
> If policy initialization fails after the sysfs files are created,
> there is a possibility that we may end up running show()/store()
> callbacks for half initialized policies, which may have unpredictable
> outcomes.
>
> Abort show/store in such a case by making sure the policy is active.
> Also inactivate the policy on such failures.
>
Yes, I think it's OK, let me upload a new patch V5 for it ?
>> Signed-off-by: Schspa Shi <schspa@gmail.com>
>>
>> ---
>>
>> Changelog:
>> v1 -> v2:
>> - Fix bad critical region enlarge which causes uninitialized
>> unlock.
>> - Move cpumask_clear(policy->cpus); before out_offline_policy
>> v2 -> v3:
>> - Remove the missed down_write() before
>> cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);
>> v3 -> v4:
>> - Seprate to two patchs.
>> - Add policy_is_inactive check before sysfs access
>> ---
>> drivers/cpufreq/cpufreq.c | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 80f535cc8a75..35dffd738580 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -953,7 +953,10 @@ static ssize_t show(struct kobject *kobj, struct attribute *attr, char *buf)
>> return -EIO;
>>
>> down_read(&policy->rwsem);
>> - ret = fattr->show(policy, buf);
>> + if (unlikely(policy_is_inactive(policy)))
>> + ret = -EBUSY;
>> + else
>> + ret = fattr->show(policy, buf);
>
> I like it the way I have done earlier, initialize ret to -EBUSY and
> get rid of the else part and call show/store in if itself. Same for
> below.
>
I add a unlikely here, to avoid branch prediction failed. And move the
to the fail path to avoid a register assignment to -EBUSY.
I think it's better for performance.
You can verify this at the disassamble of show function.
(gdb) disassemble /s show
Dump of assembler code for function show:
0x00000000000037b8 <+0>: paciasp
0x00000000000037bc <+4>: stp x29, x30, [sp, #-48]!
0x00000000000037c0 <+8>: ldr x8, [x1, #16]
0x00000000000037c4 <+12>: stp x22, x21, [sp, #16]
0x00000000000037c8 <+16>: stp x20, x19, [sp, #32]
0x00000000000037cc <+20>: mov x29, sp
0x00000000000037d0 <+24>: cbz x8, 0x3820 <show+104>
0x00000000000037d4 <+28>: sub x22, x0, #0x1b8
0x00000000000037d8 <+32>: add x19, x22, #0x218
0x00000000000037dc <+36>: mov x0, x19
0x00000000000037e0 <+40>: mov x20, x2
0x00000000000037e4 <+44>: mov x21, x1
0x00000000000037e8 <+48>: bl 0x37e8 <show+48>
0x00000000000037ec <+52>: mov w1, #0x100 // #256
0x00000000000037f0 <+56>: mov x0, x22
0x00000000000037f4 <+60>: bl 0x37f4 <show+60>
0x00000000000037f8 <+64>: cmp x0, #0x100
0x00000000000037fc <+68>: b.eq 0x383c <show+132> // b.none
// use unlikely to avoid branch prediction failed
0x0000000000003800 <+72>: ldr x8, [x21, #16]
0x0000000000003804 <+76>: mov x0, x22
0x0000000000003808 <+80>: mov x1, x20
0x000000000000380c <+84>: blr x8
0x0000000000003810 <+88>: mov x20, x0
0x0000000000003814 <+92>: mov x0, x19
0x0000000000003818 <+96>: bl 0x3818 <show+96>
0x000000000000381c <+100>: b 0x3824 <show+108>
0x0000000000003820 <+104>: mov x20, #0xfffffffffffffffb // #-5
0x0000000000003824 <+108>: mov x0, x20
0x0000000000003828 <+112>: ldp x20, x19, [sp, #32]
0x000000000000382c <+116>: ldp x22, x21, [sp, #16]
0x0000000000003830 <+120>: ldp x29, x30, [sp], #48
0x0000000000003834 <+124>: autiasp
0x0000000000003838 <+128>: ret
0x000000000000383c <+132>: mov x20, #0xfffffffffffffff0 // #-16
// this is ret = -EBUSY, which will not be assigned under normal
circumstances
0x0000000000003840 <+136>: b 0x3814 <show+92>
>> up_read(&policy->rwsem);
>>
>> return ret;
>> @@ -978,7 +981,10 @@ static ssize_t store(struct kobject *kobj, struct attribute *attr,
>>
>> if (cpu_online(policy->cpu)) {
>> down_write(&policy->rwsem);
>> - ret = fattr->store(policy, buf, count);
>> + if (unlikely(policy_is_inactive(policy)))
>> + ret = -EBUSY;
>> + else
>> + ret = fattr->store(policy, buf, count);
>> up_write(&policy->rwsem);
>> }
>>
>> @@ -1533,6 +1539,7 @@ static int cpufreq_online(unsigned int cpu)
>> for_each_cpu(j, policy->real_cpus)
>> remove_cpu_dev_symlink(policy, get_cpu_device(j));
>>
>> + cpumask_clear(policy->cpus);
>> up_write(&policy->rwsem);
>>
>> out_offline_policy:
>> --
>> 2.29.0
--
Schspa Shi
BRs
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/2] cpufreq: fix race on cpufreq online
2022-05-13 6:06 ` Schspa Shi
@ 2022-05-13 6:13 ` Viresh Kumar
2022-05-13 11:16 ` Schspa Shi
0 siblings, 1 reply; 11+ messages in thread
From: Viresh Kumar @ 2022-05-13 6:13 UTC (permalink / raw)
To: Schspa Shi; +Cc: Rafael J. Wysocki, Linux PM, Linux Kernel Mailing List
On 13-05-22, 14:06, Schspa Shi wrote:
> Viresh Kumar <viresh.kumar@linaro.org> writes:
> > On 12-05-22, 21:52, Schspa Shi wrote:
> >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> >> index 80f535cc8a75..35dffd738580 100644
> >> --- a/drivers/cpufreq/cpufreq.c
> >> +++ b/drivers/cpufreq/cpufreq.c
> >> @@ -953,7 +953,10 @@ static ssize_t show(struct kobject *kobj, struct attribute *attr, char *buf)
> >> return -EIO;
> >>
> >> down_read(&policy->rwsem);
> >> - ret = fattr->show(policy, buf);
> >> + if (unlikely(policy_is_inactive(policy)))
> >> + ret = -EBUSY;
> >> + else
> >> + ret = fattr->show(policy, buf);
> >
> > I like it the way I have done earlier, initialize ret to -EBUSY and
> > get rid of the else part and call show/store in if itself. Same for
> > below.
> >
>
> I add a unlikely here, to avoid branch prediction failed.
I am not asking you to drop it, I also added the unlikely within the
implementation of policy_is_inactive() then. It can be written as:
if (likely(!policy_is_inactive(policy)))
ret = fattr->show(policy, buf);
> And move the
> to the fail path to avoid a register assignment to -EBUSY.
We don't care about such assignments for performance to be honest.
This makes the code smaller by few lines, that's enough.
--
viresh
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/2] cpufreq: fix race on cpufreq online
2022-05-13 6:13 ` Viresh Kumar
@ 2022-05-13 11:16 ` Schspa Shi
0 siblings, 0 replies; 11+ messages in thread
From: Schspa Shi @ 2022-05-13 11:16 UTC (permalink / raw)
To: Viresh Kumar; +Cc: Rafael J. Wysocki, Linux PM, Linux Kernel Mailing List
Viresh Kumar <viresh.kumar@linaro.org> writes:
> On 13-05-22, 14:06, Schspa Shi wrote:
>> Viresh Kumar <viresh.kumar@linaro.org> writes:
>> > On 12-05-22, 21:52, Schspa Shi wrote:
>> >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> >> index 80f535cc8a75..35dffd738580 100644
>> >> --- a/drivers/cpufreq/cpufreq.c
>> >> +++ b/drivers/cpufreq/cpufreq.c
>> >> @@ -953,7 +953,10 @@ static ssize_t show(struct kobject *kobj, struct attribute *attr, char *buf)
>> >> return -EIO;
>> >>
>> >> down_read(&policy->rwsem);
>> >> - ret = fattr->show(policy, buf);
>> >> + if (unlikely(policy_is_inactive(policy)))
>> >> + ret = -EBUSY;
>> >> + else
>> >> + ret = fattr->show(policy, buf);
>> >
>> > I like it the way I have done earlier, initialize ret to -EBUSY and
>> > get rid of the else part and call show/store in if itself. Same for
>> > below.
>> >
>>
>> I add a unlikely here, to avoid branch prediction failed.
>
> I am not asking you to drop it, I also added the unlikely within the
> implementation of policy_is_inactive() then. It can be written as:
>
> if (likely(!policy_is_inactive(policy)))
> ret = fattr->show(policy, buf);
>
>> And move the
>> to the fail path to avoid a register assignment to -EBUSY.
>
> We don't care about such assignments for performance to be honest.
> This makes the code smaller by few lines, that's enough.
OK, I have uploaded a v5 patch for this. Please review it.
--
Schspa Shi
BRs
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [cpufreq] 0a020f0eff: WARNING:possible_recursive_locking_detected
[not found] ` <20220515095313.GE10578@xsang-OptiPlex-9020>
@ 2022-05-16 2:35 ` Schspa Shi
0 siblings, 0 replies; 11+ messages in thread
From: Schspa Shi @ 2022-05-16 2:35 UTC (permalink / raw)
To: kernel test robot
Cc: 0day robot, LKML, lkp, Rafael J. Wysocki, Viresh Kumar, Linux PM
kernel test robot <oliver.sang@intel.com> writes:
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-11):
>
> commit: 0a020f0efff0138b975eac68aebd2dd7d92df0f7 ("[PATCH v4 2/2] cpufreq: make interface functions and lock holding state clear")
> url: https://github.com/intel-lab-lkp/linux/commits/Schspa-Shi/cpufreq-fix-race-on-cpufreq-online/20220512-215524
> base: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git linux-next
> patch link: https://lore.kernel.org/linux-pm/20220512135231.10076-2-schspa@gmail.com
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
>
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot <oliver.sang@intel.com>
>
>
> [ 53.507882][ T196] WARNING: possible recursive locking detected
> [ 53.509102][ T196] 5.18.0-rc6-00115-g0a020f0efff0 #1 Not tainted
> [ 53.510334][ T196] --------------------------------------------
> [ 53.511579][ T196] systemd-udevd/196 is trying to acquire lock:
> [ 53.512814][ T196] ffff888111694380 (&policy->rwsem){+.+.}-{3:3}, at: cpufreq_policy_put_kobj (drivers/cpufreq/cpufreq.c:1184)
> [ 53.514800][ T196]
> [ 53.514800][ T196] but task is already holding lock:
> [ 53.516300][ T196] ffff888111694380 (&policy->rwsem){+.+.}-{3:3}, at: cpufreq_online (drivers/cpufreq/cpufreq.c:1348)
Dear Rafael and Vriesh:
There is a BUG as reported, I will upload a v6 patch to fix it.
> [ 53.518103][ T196]
> [ 53.518103][ T196] other info that might help us debug this:
> [ 53.521705][ T196] Possible unsafe locking scenario:
> [ 53.521705][ T196]
> [ 53.523195][ T196] CPU0
> [ 53.523945][ T196] ----
> [ 53.524704][ T196] lock(&policy->rwsem);
> [ 53.525633][ T196] lock(&policy->rwsem);
> [ 53.526557][ T196]
> [ 53.526557][ T196] *** DEADLOCK ***
> [ 53.526557][ T196]
> [ 53.528280][ T196] May be due to missing lock nesting notation
> [ 53.528280][ T196]
> [ 53.529983][ T196] 3 locks held by systemd-udevd/196:
> [ 53.531030][ T196] #0: ffffffff9fb79450 (cpu_hotplug_lock){++++}-{0:0}, at: cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2828)
> [ 53.535189][ T196] #1: ffff88839684a918 (subsys mutex#6){+.+.}-{3:3}, at: subsys_interface_register (drivers/base/bus.c:1033)
> [ 53.537294][ T196] #2: ffff888111694380 (&policy->rwsem){+.+.}-{3:3}, at: cpufreq_online (drivers/cpufreq/cpufreq.c:1348)
> [ 53.539185][ T196]
> [ 53.539185][ T196] stack backtrace:
> [ 53.541720][ T196] CPU: 1 PID: 196 Comm: systemd-udevd Not tainted 5.18.0-rc6-00115-g0a020f0efff0 #1
> [ 53.543593][ T196] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014
> [ 53.545677][ T196] Call Trace:
> [ 53.546400][ T196] <TASK>
> [ 53.547091][ T196] dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))
> [ 53.548093][ T196] validate_chain.cold (kernel/locking/lockdep.c:2958 kernel/locking/lockdep.c:3001 kernel/locking/lockdep.c:3790)
> [ 53.549116][ T196] ? check_prev_add (kernel/locking/lockdep.c:3759)
> [ 53.550146][ T196] ? lock_release (kernel/locking/lockdep.c:436 kernel/locking/lockdep.c:5663)
> [ 53.551118][ T196] ? start_flush_work (kernel/workqueue.c:3057)
> [ 53.552186][ T196] __lock_acquire (kernel/locking/lockdep.c:5029)
> [ 53.553152][ T196] lock_acquire (kernel/locking/lockdep.c:436 kernel/locking/lockdep.c:5643 kernel/locking/lockdep.c:5606)
> [ 53.554068][ T196] ? cpufreq_policy_put_kobj (drivers/cpufreq/cpufreq.c:1184)
> [ 53.555173][ T196] ? rcu_read_unlock (include/linux/rcupdate.h:723 (discriminator 5))
> [ 53.556197][ T196] ? mark_held_locks (kernel/locking/lockdep.c:4208)
> [ 53.557189][ T196] ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4501)
> [ 53.558486][ T196] ? lock_is_held_type (kernel/locking/lockdep.c:5382 kernel/locking/lockdep.c:5684)
> [ 53.559880][ T196] down_write (include/linux/instrumented.h:101 include/linux/atomic/atomic-instrumented.h:1779 kernel/locking/rwsem.c:254 kernel/locking/rwsem.c:1258 kernel/locking/rwsem.c:1268 kernel/locking/rwsem.c:1515)
> [ 53.560771][ T196] ? cpufreq_policy_put_kobj (drivers/cpufreq/cpufreq.c:1184)
> [ 53.561868][ T196] ? down_write_killable_nested (kernel/locking/rwsem.c:1512)
> [ 53.563032][ T196] ? rcu_read_lock_sched_held (kernel/rcu/update.c:125)
> [ 53.564180][ T196] ? kfree (include/trace/events/kmem.h:118 mm/slub.c:4541)
> [ 53.565075][ T196] cpufreq_policy_put_kobj (drivers/cpufreq/cpufreq.c:1184)
> [ 53.566190][ T196] cpufreq_policy_free (drivers/cpufreq/cpufreq.c:1319)
> [ 53.567207][ T196] cpufreq_online (drivers/cpufreq/cpufreq.c:1556)
> [ 53.569227][ T196] ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4501)
> [ 53.570546][ T196] ? _raw_spin_unlock_irqrestore (arch/x86/include/asm/irqflags.h:45 arch/x86/include/asm/irqflags.h:80 arch/x86/include/asm/irqflags.h:138 include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194)
> [ 53.573947][ T196] cpufreq_add_dev (drivers/cpufreq/cpufreq.c:1572)
> [ 53.574901][ T196] subsys_interface_register (drivers/base/bus.c:990 drivers/base/bus.c:1036)
> [ 53.576041][ T196] ? subsys_interface_unregister (drivers/base/bus.c:1020)
> [ 53.577226][ T196] cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2855)
> [ 53.578302][ T196] acpi_cpufreq_init (drivers/cpufreq/acpi-cpufreq.c:348) acpi_cpufreq
> [ 53.579542][ T196] ? acpi_cpufreq_boost_init (drivers/cpufreq/acpi-cpufreq.c:929) acpi_cpufreq
> [ 53.580875][ T196] do_one_initcall (init/main.c:1298)
> [ 53.581831][ T196] ? trace_event_raw_event_initcall_level (init/main.c:1289)
> [ 53.583183][ T196] ? rcu_read_lock_sched_held (kernel/rcu/update.c:125)
> [ 53.584633][ T196] ? kasan_unpoison (mm/kasan/shadow.c:108 mm/kasan/shadow.c:142)
> [ 53.585598][ T196] do_init_module (kernel/module.c:3731)
> [ 53.586564][ T196] __do_sys_finit_module (kernel/module.c:4222)
> [ 53.587619][ T196] ? __ia32_sys_init_module (kernel/module.c:4190)
> [ 53.588681][ T196] ? __seccomp_filter (arch/x86/include/asm/bitops.h:214 include/asm-generic/bitops/instrumented-non-atomic.h:135 kernel/seccomp.c:351 kernel/seccomp.c:378 kernel/seccomp.c:410 kernel/seccomp.c:1183)
> [ 53.589738][ T196] ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4501)
> [ 53.593133][ T196] do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
> [ 53.594043][ T196] ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4501)
> [ 53.595344][ T196] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:115)
> [ 53.596430][ T196] RIP: 0033:0x7f4373b51f59
> [ 53.597308][ T196] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 07 6f 0c 00 f7 d8 64 89 01 48
> All code
> ========
> 0: 00 c3 add %al,%bl
> 2: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
> 9: 00 00 00
> c: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> 11: 48 89 f8 mov %rdi,%rax
> 14: 48 89 f7 mov %rsi,%rdi
> 17: 48 89 d6 mov %rdx,%rsi
> 1a: 48 89 ca mov %rcx,%rdx
> 1d: 4d 89 c2 mov %r8,%r10
> 20: 4d 89 c8 mov %r9,%r8
> 23: 4c 8b 4c 24 08 mov 0x8(%rsp),%r9
> 28: 0f 05 syscall
> 2a:* 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax <-- trapping instruction
> 30: 73 01 jae 0x33
> 32: c3 retq
> 33: 48 8b 0d 07 6f 0c 00 mov 0xc6f07(%rip),%rcx # 0xc6f41
> 3a: f7 d8 neg %eax
> 3c: 64 89 01 mov %eax,%fs:(%rcx)
> 3f: 48 rex.W
>
> Code starting with the faulting instruction
> ===========================================
> 0: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax
> 6: 73 01 jae 0x9
> 8: c3 retq
> 9: 48 8b 0d 07 6f 0c 00 mov 0xc6f07(%rip),%rcx # 0xc6f17
> 10: f7 d8 neg %eax
> 12: 64 89 01 mov %eax,%fs:(%rcx)
> 15: 48 rex.W
> [ 53.600905][ T196] RSP: 002b:00007fffb900dc68 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
> [ 53.602564][ T196] RAX: ffffffffffffffda RBX: 000055ccf555cd00 RCX: 00007f4373b51f59
> [ 53.604332][ T196] RDX: 0000000000000000 RSI: 00007f4373a56cad RDI: 0000000000000006
> [ 53.605910][ T196] RBP: 00007f4373a56cad R08: 0000000000000000 R09: 000055ccf5541be0
> [ 53.607549][ T196] R10: 0000000000000006 R11: 0000000000000246 R12: 0000000000000000
> [ 53.609140][ T196] R13: 000055ccf5567130 R14: 0000000000020000 R15: 000055ccf555cd00
> [ 53.610725][ T196] </TASK>
> [ OK ] Started D-Bus System Message Bus.
> [ OK ] Started Daily apt download activities.
> [ OK ] Started Daily apt upgrade and clean activities.
> Starting System Logging Service...
> [ OK ] Started Daily rotation of log files.
> [ OK ] Reached target Timers.
> Starting LSB: OpenIPMI Driver init script...
> [ OK ] Started Helper to synchronize boot up for ifupdown.
> [ 54.028963][ T200] piix4_smbus 0000:00:01.3: SMBus Host Controller at 0x700, revision 0
> Starting LSB: Load kernel image with kexec...
> Starting Raise network interfaces...
> [ OK ] Started Login Service.
> [ 54.258656][ T225] IPMI message handler: version 39.2
> [ 54.291478][ T225] ipmi device interface
> [ OK ] Started LSB: Load kernel image with kexec.
> [ OK ] Started Raise network interfaces.
> [ 54.379602][ T178] RAPL PMU: API unit is 2^-32 Joules, 0 fixed counters, 10737418240 ms ovfl timer
> [ OK ] Reached target Network.
> [ 54.413487][ T199] libata version 3.00 loaded.
> Starting Permit User Sessions...
> [ 54.460902][ T244] ipmi_si: IPMI System Interface driver
> [ 54.462665][ T244] ipmi_si: Unable to find any System Interface(s)
> Starting /etc/rc.local Compatibility...
> [ 54.500918][ T198] parport_pc 00:03: reported by Plug and Play ACPI
> Starting OpenBSD Secure Shell server...
> [ 54.566683][ T198] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
> Starting LKP bootstrap...
> [FAILED] Failed to start LSB: OpenIPMI Driver init script.
> See 'systemctl status openipmi.service' for details.
> [ 54.508949] rc.local[250]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/lkp/lkp/src/bin
> [ OK ] Started Permit User Sessions.
> [ OK ] Started /etc/rc.local Compatibility.
> [ 54.685664][ T199] ata_piix 0000:00:01.1: version 2.13
> [ 54.579006] rc.local[250]: /lkp/lkp/src/bin/lkp-setup-rootfs: 78: /lkp/lkp/src/bin/lkp-setup-rootfs: cannot create /sys/devices/system/cpu/microcode/reload: Directory nonexistent
> [ OK ] Started Getty on tty1.
> [ OK ] Reached target Login Prompts.
> [ OK ] Started OpenBSD Secure Shell server.
> [ 54.848488][ T199] scsi host0: ata_piix
> [ 54.890906][ T199] scsi host1: ata_piix
> [ 54.901762][ T199] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc040 irq 14
>
>
> To reproduce:
>
> # build kernel
> cd linux
> cp config-5.18.0-rc6-00115-g0a020f0efff0 .config
> make HOSTCC=gcc-11 CC=gcc-11 ARCH=x86_64 olddefconfig prepare modules_prepare bzImage modules
> make HOSTCC=gcc-11 CC=gcc-11 ARCH=x86_64 INSTALL_MOD_PATH=<mod-install-dir> modules_install
> cd <mod-install-dir>
> find lib/ | cpio -o -H newc --quiet | gzip > modules.cgz
>
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k <bzImage> -m modules.cgz job-script # job-script is attached in this email
>
> # if come across any failure that blocks the test,
> # please remove ~/.lkp and /lkp dir to run from a clean state.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-05-16 2:35 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-05-12 13:52 [PATCH v4 1/2] cpufreq: fix race on cpufreq online Schspa Shi
2022-05-12 13:52 ` [PATCH v4 2/2] cpufreq: make interface functions and lock holding state clear Schspa Shi
2022-05-12 14:44 ` Rafael J. Wysocki
2022-05-12 16:01 ` Schspa Shi
2022-05-12 16:23 ` Rafael J. Wysocki
2022-05-13 4:29 ` Viresh Kumar
[not found] ` <20220515095313.GE10578@xsang-OptiPlex-9020>
2022-05-16 2:35 ` [cpufreq] 0a020f0eff: WARNING:possible_recursive_locking_detected Schspa Shi
2022-05-13 4:18 ` [PATCH v4 1/2] cpufreq: fix race on cpufreq online Viresh Kumar
2022-05-13 6:06 ` Schspa Shi
2022-05-13 6:13 ` Viresh Kumar
2022-05-13 11:16 ` Schspa Shi
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).