Skip to contentSkip to conversation

MIPS: Octeon: fix for held reboot_mutex lock at task exit time

PATCH In review Wladislav Wiebe 4 participants 4 messages May 23, 2013 – Jun 28, 2013 MIPS

lore
Share & tools
lore

Wladislav Wiebe

author
#0 lore raw

PATCH v2 1/1 MIPS: Octeon: fix for held reboot_mutex lock at task exit time

When kernel halt's will reboot_mutex lock still hold at exit. It will issue with 'halt' command:

$ halt
..
Sent SIGKILL to all processes
Requesting system halt
[66.729373] System halted.
[66.733244]
[66.734761] =====================================
[66.739473] [ BUG: lock held at task exit time! ]
[66.744188] 3.8.7-0-sampleversion-fct #49 Tainted: G           O
[66.750202] -------------------------------------
[66.754913] init/21479 is exiting with locks still held!
[66.760234] 1 lock held by init/21479:
[66.763990]  #0:  (reboot_mutex){+.+...}, at: [<ffffffff801776c8>] SyS_reboot+0xe0/0x218
[66.772165]
[66.772165] stack backtrace:
[66.776532] Call Trace:
[66.778992] [<ffffffff805780a8>] dump_stack+0x8/0x34
[66.783972] [<ffffffff801618b0>] do_exit+0x610/0xa70
[66.788948] [<ffffffff801777a8>] SyS_reboot+0x1c0/0x218
[66.794186] [<ffffffff8013d6a4>] handle_sys64+0x44/0x64

With this commit we will still have a proper halt sequence
and the reboot_mutex held bug is gone: (added printk's to affected functions)

$ halt
..
ent SIGKILL to all processes
Requesting system halt
[70.258665] DBG: kernel/sys.c, 486, SYSC_reboot: (case LINUX_REBOOT_CMD_HALT:)
[70.268953] DBG: kernel/sys.c, 396, kernel_halt: (kernel_shutdown_prepare(..);)
[70.284069] DBG: kernel/sys.c, 398, kernel_halt: (syscore_shutdown();)
[70.294364] DBG: kernel/sys.c, 400, kernel_halt: (kmsg_dump(KMSG_DUMP_HALT);)
[70.304640] System halted.
[70.307363] DBG: kernel/sys.c, 403, kernel_halt: (machine_halt();)
[70.317640] DBG: arch/mips/cavium-octeon/setup.c, 502, octeon_halt:
[70.329582] DBG: arch/mips/cavium-octeon/setup.c, 485, octeon_kill_core: (core1)
[70.329588] DBG: arch/mips/cavium-octeon/setup.c, 485, octeon_kill_core: (core2)
[70.329594] DBG: arch/mips/cavium-octeon/setup.c, 485, octeon_kill_core: (core3)
[70.329600] DBG: arch/mips/cavium-octeon/setup.c, 485, octeon_kill_core: (core4)
[70.329607] DBG: arch/mips/cavium-octeon/setup.c, 485, octeon_kill_core: (core5)
[70.329614] DBG: arch/mips/cavium-octeon/setup.c, 485, octeon_kill_core: (core6)

In this case on a 6 Core Cavium Octeon board.

Acked-by Maxim Uvarov <[email protected]>
Signed-off-by Wladislav Wiebe <[email protected]>
---
 arch/mips/cavium-octeon/setup.c |    4 ++++
 1 file changed, 4 insertions(+)
arch/mips/cavium-octeon/setup.c +4 -0
index b0baa29..04ce396 100644
@@ -457,6 +457,10 @@ static void octeon_halt(void)
 	}
 
 	octeon_kill_core(NULL);
+
+	/* We stop here */
+	while (1)
+		;
 }
 
 /**
Signature · 1 line
1.7.9.5
#1 lore raw
Quoted 24 lines · Wladislav Wiebe

When kernel halt's will reboot_mutex lock still hold at exit. It will issue with 'halt' command:

$ halt
..
Sent SIGKILL to all processes
Requesting system halt
[66.729373] System halted.
[66.733244]
[66.734761] =====================================
[66.739473] [ BUG: lock held at task exit time! ]
[66.744188] 3.8.7-0-sampleversion-fct #49 Tainted: G           O
[66.750202] -------------------------------------
[66.754913] init/21479 is exiting with locks still held!
[66.760234] 1 lock held by init/21479:
[66.763990]  #0:  (reboot_mutex){+.+...}, at: [<ffffffff801776c8>] SyS_reboot+0xe0/0x218
[66.772165]
[66.772165] stack backtrace:
[66.776532] Call Trace:
[66.778992] [<ffffffff805780a8>] dump_stack+0x8/0x34
[66.783972] [<ffffffff801618b0>] do_exit+0x610/0xa70
[66.788948] [<ffffffff801777a8>] SyS_reboot+0x1c0/0x218
[66.794186] [<ffffffff8013d6a4>] handle_sys64+0x44/0x64

[...]

Quoted 12 lines
Acked-by Maxim Uvarov <[email protected]>
Signed-off-by Wladislav Wiebe <[email protected]>
---
  arch/mips/cavium-octeon/setup.c |    4 ++++
  1 file changed, 4 insertions(+)
arch/mips/cavium-octeon/setup.c +0 -0
index b0baa29..04ce396 100644

arch/mips/cavium-octeon/setup.c static void octeon_halt(void) · line 463

Quoted 7 lines
arch/mips/cavium-octeon/setup.c +4 -0
@@ -457,6 +457,10 @@ static void octeon_halt(void)
  	}
 
  	octeon_kill_core(NULL);
+
+	/* We stop here */
+	while (1)
+		;

I want to put a WAIT here so we don't burn so much power.

I will send a patch to do that instead.

Quoted 4 lines
arch/mips/cavium-octeon/setup.c +0 -0
  }
 
  /**
#2 lore raw

2013/5/23 David Daney <[email protected]>

Quoted 53 lines · Wladislav Wiebe
Quoted 41 lines

When kernel halt's will reboot_mutex lock still hold at exit. It will issue with 'halt' command:

$ halt
..
Sent SIGKILL to all processes
Requesting system halt
[66.729373] System halted.
[66.733244]
[66.734761] ==============================**=======
[66.739473] [ BUG: lock held at task exit time! ]
[66.744188] 3.8.7-0-sampleversion-fct #49 Tainted: G           O
[66.750202] ------------------------------**-------
[66.754913] init/21479 is exiting with locks still held!
[66.760234] 1 lock held by init/21479:
[66.763990]  #0:  (reboot_mutex){+.+...}, at: [<ffffffff801776c8>]
SyS_reboot+0xe0/0x218
[66.772165]
[66.772165] stack backtrace:
[66.776532] Call Trace:
[66.778992] [<ffffffff805780a8>] dump_stack+0x8/0x34
[66.783972] [<ffffffff801618b0>] do_exit+0x610/0xa70
[66.788948] [<ffffffff801777a8>] SyS_reboot+0x1c0/0x218
[66.794186] [<ffffffff8013d6a4>] handle_sys64+0x44/0x64

[...]

Acked-by Maxim Uvarov <[email protected]>
Signed-off-by Wladislav Wiebe <[email protected]>
---
  arch/mips/cavium-octeon/setup.**c |    4 ++++
  1 file changed, 4 insertions(+)
arch/mips/cavium-octeon/ renamed from arch/mips/cavium-octeon/**setup.c +0 -0

**setup.c
index b0baa29..04ce396 100644

arch/mips/cavium-octeon/**setup.c static void octeon_halt(void) · line 464

Quoted 8 lines
arch/mips/cavium-octeon/**setup.c +4 -0
@@ -457,6 +457,10 @@ static void octeon_halt(void)
        }
 
        octeon_kill_core(NULL);
+
+       /* We stop here */
+       while (1)
+               ;

I want to put a WAIT here so we don't burn so much power.

Quoted 3 lines

I will send a patch to do that instead.

what about adding wait for other mips boards where is while (1) is used?

Maxim.

Quoted 6 lines
   }
Quoted 4 lines
arch/mips/cavium-octeon/**setup.c +0 -0
  /**
Signature · 2 lines
Best regards,
Maxim Uvarov
#3 lore raw

Sorry for the late reply - this ended up in the moderator queue for the mailing list and I rarely look at it - it's tens of thousands of emails!

Quoted 17 lines · Maxim Uvarov
Quoted 17 lines
Quoted 6 lines
arch/mips/cavium-octeon/ renamed from arch/mips/cavium-octeon/**setup.c +0 -0

**setup.c
index b0baa29..04ce396 100644

arch/mips/cavium-octeon/**setup.c static void octeon_halt(void) · line 464

Quoted 8 lines
arch/mips/cavium-octeon/**setup.c +4 -0
@@ -457,6 +457,10 @@ static void octeon_halt(void)
        }
 
        octeon_kill_core(NULL);
+
+       /* We stop here */
+       while (1)
+               ;

I want to put a WAIT here so we don't burn so much power.

Quoted 4 lines
Quoted 3 lines

I will send a patch to do that instead.

what about adding wait for other mips boards where is while (1) is used?

Many platforms have their own variants of eternal loops, some using just "while (1);", others trying to save power using the WAIT instruction. I was planing to work through all of them and come up with a common defaut implementation.

Ralf