mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v2] init: Align init_task to avoid conflict with MUTEX_FLAGS
@ 2020-06-26 21:07 Stafford Horne
  2020-07-02  1:09 ` Stafford Horne
  0 siblings, 1 reply; 2+ messages in thread
From: Stafford Horne @ 2020-06-26 21:07 UTC (permalink / raw)
  To: LKML
  Cc: Stafford Horne, Peter Zijlstra, Paul E. McKenney, Marco Elver,
	Eric W. Biederman, Ingo Molnar, Thomas Gleixner, Mike Rapoport,
	Sami Tolvanen

When booting on 32-bit machines (seen on OpenRISC) I saw this warning
with CONFIG_DEBUG_MUTEXES turned on.

    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 0 at kernel/locking/mutex.c:1242 __mutex_unlock_slowpath+0x328/0x3ec
    DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
    Modules linked in:
    CPU: 0 PID: 0 Comm: swapper Not tainted 5.8.0-rc1-simple-smp-00005-g2864e2171db4-dirty #179
    Call trace:
    [<(ptrval)>] dump_stack+0x34/0x48
    [<(ptrval)>] __warn+0x104/0x158
    [<(ptrval)>] ? __mutex_unlock_slowpath+0x328/0x3ec
    [<(ptrval)>] warn_slowpath_fmt+0x7c/0x94
    [<(ptrval)>] __mutex_unlock_slowpath+0x328/0x3ec
    [<(ptrval)>] mutex_unlock+0x18/0x28
    [<(ptrval)>] __cpuhp_setup_state_cpuslocked.part.0+0x29c/0x2f4
    [<(ptrval)>] ? page_alloc_cpu_dead+0x0/0x30
    [<(ptrval)>] ? start_kernel+0x0/0x684
    [<(ptrval)>] __cpuhp_setup_state+0x4c/0x5c
    [<(ptrval)>] page_alloc_init+0x34/0x68
    [<(ptrval)>] ? start_kernel+0x1a0/0x684
    [<(ptrval)>] ? early_init_dt_scan_nodes+0x60/0x70
    irq event stamp: 0

I traced this to kernel/locking/mutex.c storing 3 bits of MUTEX_FLAGS in
the task_struct pointer (mutex.owner).  There is a comment saying that
task_structs are always aligned to L1_CACHE_BYTES.  This is not true for
the init_task.

On 64-bit machines this is not a problem because symbol addresses are
naturally aligned to 64-bits providing 3 bits for MUTEX_FLAGS.  Howerver,
for 32-bit machines the symbol address only has 2 bits available.

Fix this by setting init_task alignment to at least L1_CACHE_BYTES.

Signed-off-by: Stafford Horne <shorne@gmail.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
Changes since v1:
 - Make alignment unconditional suggested by Peter

 init/init_task.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/init/init_task.c b/init/init_task.c
index 15089d15010a..ab6173f8e6a8 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -65,6 +65,7 @@ struct task_struct init_task
 #ifdef CONFIG_ARCH_TASK_STRUCT_ON_STACK
 	__init_task_data
 #endif
+	__aligned(L1_CACHE_BYTES)
 = {
 #ifdef CONFIG_THREAD_INFO_IN_TASK
 	.thread_info	= INIT_THREAD_INFO(init_task),
-- 
2.26.2


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH v2] init: Align init_task to avoid conflict with MUTEX_FLAGS
  2020-06-26 21:07 [PATCH v2] init: Align init_task to avoid conflict with MUTEX_FLAGS Stafford Horne
@ 2020-07-02  1:09 ` Stafford Horne
  0 siblings, 0 replies; 2+ messages in thread
From: Stafford Horne @ 2020-07-02  1:09 UTC (permalink / raw)
  To: LKML
  Cc: Peter Zijlstra, Paul E. McKenney, Marco Elver, Eric W. Biederman,
	Ingo Molnar, Thomas Gleixner, Mike Rapoport, Sami Tolvanen

Hello,

Is there anyone willing to pick this up?

I guess I could send it in the OpenRISC queue, but it doesn't really seem like
the right thing.

-Stafford

On Sat, Jun 27, 2020 at 06:07:53AM +0900, Stafford Horne wrote:
> When booting on 32-bit machines (seen on OpenRISC) I saw this warning
> with CONFIG_DEBUG_MUTEXES turned on.
> 
>     ------------[ cut here ]------------
>     WARNING: CPU: 0 PID: 0 at kernel/locking/mutex.c:1242 __mutex_unlock_slowpath+0x328/0x3ec
>     DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
>     Modules linked in:
>     CPU: 0 PID: 0 Comm: swapper Not tainted 5.8.0-rc1-simple-smp-00005-g2864e2171db4-dirty #179
>     Call trace:
>     [<(ptrval)>] dump_stack+0x34/0x48
>     [<(ptrval)>] __warn+0x104/0x158
>     [<(ptrval)>] ? __mutex_unlock_slowpath+0x328/0x3ec
>     [<(ptrval)>] warn_slowpath_fmt+0x7c/0x94
>     [<(ptrval)>] __mutex_unlock_slowpath+0x328/0x3ec
>     [<(ptrval)>] mutex_unlock+0x18/0x28
>     [<(ptrval)>] __cpuhp_setup_state_cpuslocked.part.0+0x29c/0x2f4
>     [<(ptrval)>] ? page_alloc_cpu_dead+0x0/0x30
>     [<(ptrval)>] ? start_kernel+0x0/0x684
>     [<(ptrval)>] __cpuhp_setup_state+0x4c/0x5c
>     [<(ptrval)>] page_alloc_init+0x34/0x68
>     [<(ptrval)>] ? start_kernel+0x1a0/0x684
>     [<(ptrval)>] ? early_init_dt_scan_nodes+0x60/0x70
>     irq event stamp: 0
> 
> I traced this to kernel/locking/mutex.c storing 3 bits of MUTEX_FLAGS in
> the task_struct pointer (mutex.owner).  There is a comment saying that
> task_structs are always aligned to L1_CACHE_BYTES.  This is not true for
> the init_task.
> 
> On 64-bit machines this is not a problem because symbol addresses are
> naturally aligned to 64-bits providing 3 bits for MUTEX_FLAGS.  Howerver,
> for 32-bit machines the symbol address only has 2 bits available.
> 
> Fix this by setting init_task alignment to at least L1_CACHE_BYTES.
> 
> Signed-off-by: Stafford Horne <shorne@gmail.com>
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> Changes since v1:
>  - Make alignment unconditional suggested by Peter
> 
>  init/init_task.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/init/init_task.c b/init/init_task.c
> index 15089d15010a..ab6173f8e6a8 100644
> --- a/init/init_task.c
> +++ b/init/init_task.c
> @@ -65,6 +65,7 @@ struct task_struct init_task
>  #ifdef CONFIG_ARCH_TASK_STRUCT_ON_STACK
>  	__init_task_data
>  #endif
> +	__aligned(L1_CACHE_BYTES)
>  = {
>  #ifdef CONFIG_THREAD_INFO_IN_TASK
>  	.thread_info	= INIT_THREAD_INFO(init_task),
> -- 
> 2.26.2
> 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-07-02  1:09 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-26 21:07 [PATCH v2] init: Align init_task to avoid conflict with MUTEX_FLAGS Stafford Horne
2020-07-02  1:09 ` Stafford Horne

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®