All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: <catalin.marinas@arm.com>, <will@kernel.org>, <rjw@rjwysocki.net>,
	<viresh.kumar@linaro.org>, <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
	<guohanjun@huawei.com>
Subject: Re: [PATCH] ACPI / PPTT: get PPTT table in the first beginning
Date: Wed, 21 Jul 2021 09:25:23 +0800	[thread overview]
Message-ID: <1c9112c0-8a3e-e82e-8c88-377e3d4e9e18@huawei.com> (raw)
In-Reply-To: <20210720133751.u6k6bdm7qco3gn65@bogus>

Hi Sudeep,

On 2021/7/20 21:37, Sudeep Holla wrote:
> On Tue, Jul 20, 2021 at 07:26:35PM +0800, Xiongfeng Wang wrote:
>> When I added might_sleep() in down_timeout(), I got the following
> 
> Sorry it is not clear if you are able to reproduce this issue without
> any other modifications in the mainline kernel ?

Without any modifications, the mainline kernel does not print the Calltrace. But
the risk of sleeping in atomic context still exists.

> 
>> Calltrace:
>>
>> [    8.775671] BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:160
>> [    8.777070] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 14, name: cpuhp/0
> 
>>From this I guess you are adding sleep after raw_spin_lock_irqsave
> in down_timeout(kernel/locking/semaphore.c).

I add 'might_sleep()' which is used to check whether there are problems if I
sleep here. It's not a real sleep.

The Document for might_sleep is as below.
/**
 * might_sleep - annotation for functions that can sleep

 *
 * this macro will print a stack trace if it is executed in an atomic
 * context (spinlock, irq-handler, ...). Additional sections where blocking is
 * not allowed can be annotated with non_block_start() and non_block_end()
 * pairs.
 *
 * This is a useful debugging help to be able to catch problems early and not
 * be bitten later when the calling function happens to sleep when it is not
 * supposed to.
 */

> 
>>
>> It is because generic_exec_single() will disable local irq before
>> calling _init_cache_level(). _init_cache_level() use acpi_get_table() to
>> get the PPTT table, but this function could schedule out.
>>
>> To fix this issue, we use a static pointer to record the mapped PPTT
>> table in the first beginning. Later, we use that pointer to reference
>> the PPTT table in acpi_find_last_cache_level(). We also modify other
>> functions in pptt.c to use the pointer to reference PPTT table.

The main problem is that we called local_irq_save() in generic_exec_single(),
and then we called down_timeout() in acpi_os_wait_semaphore(). down_timeout()
could enter into sleep if failed to acquire the semaphore. There are risks of
sleeping in irq disabled context.

Thanks,
Xiongfeng

>>
> 
> I don't follow this change at all.
> 

WARNING: multiple messages have this Message-ID (diff)
From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: <catalin.marinas@arm.com>, <will@kernel.org>, <rjw@rjwysocki.net>,
	<viresh.kumar@linaro.org>, <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
	<guohanjun@huawei.com>
Subject: Re: [PATCH] ACPI / PPTT: get PPTT table in the first beginning
Date: Wed, 21 Jul 2021 09:25:23 +0800	[thread overview]
Message-ID: <1c9112c0-8a3e-e82e-8c88-377e3d4e9e18@huawei.com> (raw)
In-Reply-To: <20210720133751.u6k6bdm7qco3gn65@bogus>

Hi Sudeep,

On 2021/7/20 21:37, Sudeep Holla wrote:
> On Tue, Jul 20, 2021 at 07:26:35PM +0800, Xiongfeng Wang wrote:
>> When I added might_sleep() in down_timeout(), I got the following
> 
> Sorry it is not clear if you are able to reproduce this issue without
> any other modifications in the mainline kernel ?

Without any modifications, the mainline kernel does not print the Calltrace. But
the risk of sleeping in atomic context still exists.

> 
>> Calltrace:
>>
>> [    8.775671] BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:160
>> [    8.777070] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 14, name: cpuhp/0
> 
>>From this I guess you are adding sleep after raw_spin_lock_irqsave
> in down_timeout(kernel/locking/semaphore.c).

I add 'might_sleep()' which is used to check whether there are problems if I
sleep here. It's not a real sleep.

The Document for might_sleep is as below.
/**
 * might_sleep - annotation for functions that can sleep

 *
 * this macro will print a stack trace if it is executed in an atomic
 * context (spinlock, irq-handler, ...). Additional sections where blocking is
 * not allowed can be annotated with non_block_start() and non_block_end()
 * pairs.
 *
 * This is a useful debugging help to be able to catch problems early and not
 * be bitten later when the calling function happens to sleep when it is not
 * supposed to.
 */

> 
>>
>> It is because generic_exec_single() will disable local irq before
>> calling _init_cache_level(). _init_cache_level() use acpi_get_table() to
>> get the PPTT table, but this function could schedule out.
>>
>> To fix this issue, we use a static pointer to record the mapped PPTT
>> table in the first beginning. Later, we use that pointer to reference
>> the PPTT table in acpi_find_last_cache_level(). We also modify other
>> functions in pptt.c to use the pointer to reference PPTT table.

The main problem is that we called local_irq_save() in generic_exec_single(),
and then we called down_timeout() in acpi_os_wait_semaphore(). down_timeout()
could enter into sleep if failed to acquire the semaphore. There are risks of
sleeping in irq disabled context.

Thanks,
Xiongfeng

>>
> 
> I don't follow this change at all.
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-21  1:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-20 11:26 [PATCH] ACPI / PPTT: get PPTT table in the first beginning Xiongfeng Wang
2021-07-20 11:26 ` Xiongfeng Wang
2021-07-20 13:37 ` Sudeep Holla
2021-07-20 13:37   ` Sudeep Holla
2021-07-21  1:25   ` Xiongfeng Wang [this message]
2021-07-21  1:25     ` Xiongfeng Wang
2021-09-01  7:29   ` Zenghui Yu
2021-09-01  7:29     ` Zenghui Yu
2021-09-01  8:15     ` Hanjun Guo
2021-09-01  8:15       ` Hanjun Guo
2021-09-01  8:49       ` Zenghui Yu
2021-09-01  8:49         ` Zenghui Yu

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=1c9112c0-8a3e-e82e-8c88-377e3d4e9e18@huawei.com \
    --to=wangxiongfeng2@huawei.com \
    --cc=catalin.marinas@arm.com \
    --cc=guohanjun@huawei.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=sudeep.holla@arm.com \
    --cc=viresh.kumar@linaro.org \
    --cc=will@kernel.org \
    /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.