Blocked tasks spam kills info about which task was blocked |
|||||||||||||||||||||||||||
Issue description
I was just looking at a feedback report (#14673235681) that had a blocked task. Notably:
[ 4440.199074] Kernel panic - not syncing: hung_task: blocked tasks
[ 4440.199085] CPU: 2 PID: 40 Comm: khungtaskd Tainted: G W 4.4.21-05903-ge0514ea #1
Unfortunately there was so much spam above that I have no idea which task it was. Notably the start of console-ramoops was:
console-ramoops=<multiline>
---------- START ----------
1588.469933 14 120 9.599332 3.209207 3904987.168522 /
[ 4440.182897] minijail0 2498 9691588.444850 27 120 8.730749 6.616457 3904963.027854 /
[ 4440.182918] logger 2550 9691588.445725 44 120 11.125624 3.732166 3904922.604604 /
[ 4440.182936] tlsdated-setter 2555 9691588.446600 10 120 3.843291 3.878003 3904921.363852 /
[ 4440.182957] arc_camera_serv 2597 9691588.462933 26 120 9.404208 16.608083 3904830.164646 /
...
...
===
The source code shows:
pr_err("INFO: task %s:%d blocked for more than %ld seconds.\n",
t->comm, t->pid, timeout);
pr_err(" %s %s %.*s\n",
print_tainted(), init_utsname()->release,
(int)strcspn(init_utsname()->version, " "),
init_utsname()->version);
pr_err("\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\""
" disables this message.\n");
sched_show_task(t);
debug_show_held_locks(t);
touch_nmi_watchdog();
if (sysctl_hung_task_panic) {
/* Dump all tasks. */
show_state_filter(TASK_UNINTERRUPTIBLE);
trigger_all_cpu_backtrace();
panic("hung_task: blocked tasks");
}
===
So presumably all the sched_show_task() / debug_show_held_locks() / show_state_filter() blows through console ramoops. Doh.
Perhaps we should re-print the task that was blocked at the end? I have no idea which task was blocked in this case.
,
Oct 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/73ce7a4bc343eff5df6b125362c5beb9d880bbcb commit 73ce7a4bc343eff5df6b125362c5beb9d880bbcb Author: Douglas Anderson <dianders@chromium.org> Date: Thu Oct 27 20:33:03 2016 CHROMIUM: sched: Don't show sched debug when dumping tasks w/ filter On systems with a lot of cores and with a lot of running processes the sysrq_sched_debug_show() call can end up spewing _A LOT_ of data into the debug log. Sometimes you might want all that data, but other times you might not. One case where you might not want all that data is if you were in show_state_filter() called from check_hung_task(). Specifically: - We're probably just about to panic and so logs won't be stored to the filesystem. That means panic info might be going to some sort of persistent RAM (pstore) or a serial console. - If panic info is going to persistent RAM then we probably have limited space, like maybe 128K. - Calling sysrq_sched_debug_show() can very easily blow through 128K of space. - If we blow through the 128K of space then the super important bits printed out by check_hung_task() (the name of the task that is hung plus the stack crawls) will be cut off, rendering the log nearly useless. It seems sane to make show_state_filter() only dump this debug info when the state_filter was 0. When the state_filter is 0 then we're spewing a whole lot of data anyway and so the sched debug info shouldn't hurt. If we're only dumping _some_ of the tasks then presumably we only want info about those tasks and should avoid the extra crud. NOTE: an alternative to this fix might be to turn off SCHED_DEBUG, but that appears to have been purposefully turned on so we could implement a feature in the Chrome Browser's Task Manager. See < http://crbug.com/120488 > BUG= chromium:658937 TEST=echo HUNG_TASK > /sys/kernel/debug/provoke-crash/DIRECT Change-Id: I0d99adc02b9a4e93ef0515b9be304f06f20e8edf Fixes: 023068f26f73 ("CHROMIUM: hung_task: dump all UNINTERUPTIBLE tasks") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/404588 Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/73ce7a4bc343eff5df6b125362c5beb9d880bbcb/kernel/sched/core.c
,
Oct 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3d57cc9e507759dacf66f9d3cee132bc4fa75cc1 commit 3d57cc9e507759dacf66f9d3cee132bc4fa75cc1 Author: Douglas Anderson <dianders@chromium.org> Date: Thu Oct 27 20:33:03 2016 CHROMIUM: sched: Don't show sched debug when dumping tasks w/ filter On systems with a lot of cores and with a lot of running processes the sysrq_sched_debug_show() call can end up spewing _A LOT_ of data into the debug log. Sometimes you might want all that data, but other times you might not. One case where you might not want all that data is if you were in show_state_filter() called from check_hung_task(). Specifically: - We're probably just about to panic and so logs won't be stored to the filesystem. That means panic info might be going to some sort of persistent RAM (pstore) or a serial console. - If panic info is going to persistent RAM then we probably have limited space, like maybe 128K. - Calling sysrq_sched_debug_show() can very easily blow through 128K of space. - If we blow through the 128K of space then the super important bits printed out by check_hung_task() (the name of the task that is hung plus the stack crawls) will be cut off, rendering the log nearly useless. It seems sane to make show_state_filter() only dump this debug info when the state_filter was 0. When the state_filter is 0 then we're spewing a whole lot of data anyway and so the sched debug info shouldn't hurt. If we're only dumping _some_ of the tasks then presumably we only want info about those tasks and should avoid the extra crud. NOTE: an alternative to this fix might be to turn off SCHED_DEBUG, but that appears to have been purposefully turned on so we could implement a feature in the Chrome Browser's Task Manager. See < http://crbug.com/120488 > BUG= chromium:658937 TEST=echo HUNG_TASK > /sys/kernel/debug/provoke-crash/DIRECT Change-Id: I0d99adc02b9a4e93ef0515b9be304f06f20e8edf Fixes: 023068f26f73 ("CHROMIUM: hung_task: dump all UNINTERUPTIBLE tasks") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/404588 Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 73ce7a4bc343eff5df6b125362c5beb9d880bbcb) Reviewed-on: https://chromium-review.googlesource.com/404808 [modify] https://crrev.com/3d57cc9e507759dacf66f9d3cee132bc4fa75cc1/kernel/sched/core.c
,
Oct 28 2016
Presumably we want this on 3.18, 3.14, 3.10, 3.8 too.
,
Oct 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9159b678ebe913b7c7c61e1c8bdf6730b18ca8bb commit 9159b678ebe913b7c7c61e1c8bdf6730b18ca8bb Author: Douglas Anderson <dianders@chromium.org> Date: Thu Oct 27 20:33:03 2016 CHROMIUM: sched: Don't show sched debug when dumping tasks w/ filter On systems with a lot of cores and with a lot of running processes the sysrq_sched_debug_show() call can end up spewing _A LOT_ of data into the debug log. Sometimes you might want all that data, but other times you might not. One case where you might not want all that data is if you were in show_state_filter() called from check_hung_task(). Specifically: - We're probably just about to panic and so logs won't be stored to the filesystem. That means panic info might be going to some sort of persistent RAM (pstore) or a serial console. - If panic info is going to persistent RAM then we probably have limited space, like maybe 128K. - Calling sysrq_sched_debug_show() can very easily blow through 128K of space. - If we blow through the 128K of space then the super important bits printed out by check_hung_task() (the name of the task that is hung plus the stack crawls) will be cut off, rendering the log nearly useless. It seems sane to make show_state_filter() only dump this debug info when the state_filter was 0. When the state_filter is 0 then we're spewing a whole lot of data anyway and so the sched debug info shouldn't hurt. If we're only dumping _some_ of the tasks then presumably we only want info about those tasks and should avoid the extra crud. NOTE: an alternative to this fix might be to turn off SCHED_DEBUG, but that appears to have been purposefully turned on so we could implement a feature in the Chrome Browser's Task Manager. See < http://crbug.com/120488 > BUG= chromium:658937 TEST=echo HUNG_TASK > /sys/kernel/debug/provoke-crash/DIRECT Change-Id: I0d99adc02b9a4e93ef0515b9be304f06f20e8edf Fixes: 023068f26f73 ("CHROMIUM: hung_task: dump all UNINTERUPTIBLE tasks") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/404588 Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 73ce7a4bc343eff5df6b125362c5beb9d880bbcb) Reviewed-on: https://chromium-review.googlesource.com/404033 [modify] https://crrev.com/9159b678ebe913b7c7c61e1c8bdf6730b18ca8bb/kernel/sched/core.c
,
Oct 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6a0ab042681e25685682e8624fcf9d6799787e82 commit 6a0ab042681e25685682e8624fcf9d6799787e82 Author: Douglas Anderson <dianders@chromium.org> Date: Thu Oct 27 20:33:03 2016 CHROMIUM: sched: Don't show sched debug when dumping tasks w/ filter On systems with a lot of cores and with a lot of running processes the sysrq_sched_debug_show() call can end up spewing _A LOT_ of data into the debug log. Sometimes you might want all that data, but other times you might not. One case where you might not want all that data is if you were in show_state_filter() called from check_hung_task(). Specifically: - We're probably just about to panic and so logs won't be stored to the filesystem. That means panic info might be going to some sort of persistent RAM (pstore) or a serial console. - If panic info is going to persistent RAM then we probably have limited space, like maybe 128K. - Calling sysrq_sched_debug_show() can very easily blow through 128K of space. - If we blow through the 128K of space then the super important bits printed out by check_hung_task() (the name of the task that is hung plus the stack crawls) will be cut off, rendering the log nearly useless. It seems sane to make show_state_filter() only dump this debug info when the state_filter was 0. When the state_filter is 0 then we're spewing a whole lot of data anyway and so the sched debug info shouldn't hurt. If we're only dumping _some_ of the tasks then presumably we only want info about those tasks and should avoid the extra crud. NOTE: an alternative to this fix might be to turn off SCHED_DEBUG, but that appears to have been purposefully turned on so we could implement a feature in the Chrome Browser's Task Manager. See < http://crbug.com/120488 > BUG= chromium:658937 TEST=echo HUNG_TASK > /sys/kernel/debug/provoke-crash/DIRECT Change-Id: I0d99adc02b9a4e93ef0515b9be304f06f20e8edf Fixes: 023068f26f73 ("CHROMIUM: hung_task: dump all UNINTERUPTIBLE tasks") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/404588 Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 73ce7a4bc343eff5df6b125362c5beb9d880bbcb) Reviewed-on: https://chromium-review.googlesource.com/404770 [modify] https://crrev.com/6a0ab042681e25685682e8624fcf9d6799787e82/kernel/sched/core.c
,
Oct 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ffb80cede601023ca07727208ab78229193f8e32 commit ffb80cede601023ca07727208ab78229193f8e32 Author: Douglas Anderson <dianders@chromium.org> Date: Thu Oct 27 20:33:03 2016 CHROMIUM: sched: Don't show sched debug when dumping tasks w/ filter On systems with a lot of cores and with a lot of running processes the sysrq_sched_debug_show() call can end up spewing _A LOT_ of data into the debug log. Sometimes you might want all that data, but other times you might not. One case where you might not want all that data is if you were in show_state_filter() called from check_hung_task(). Specifically: - We're probably just about to panic and so logs won't be stored to the filesystem. That means panic info might be going to some sort of persistent RAM (pstore) or a serial console. - If panic info is going to persistent RAM then we probably have limited space, like maybe 128K. - Calling sysrq_sched_debug_show() can very easily blow through 128K of space. - If we blow through the 128K of space then the super important bits printed out by check_hung_task() (the name of the task that is hung plus the stack crawls) will be cut off, rendering the log nearly useless. It seems sane to make show_state_filter() only dump this debug info when the state_filter was 0. When the state_filter is 0 then we're spewing a whole lot of data anyway and so the sched debug info shouldn't hurt. If we're only dumping _some_ of the tasks then presumably we only want info about those tasks and should avoid the extra crud. NOTE: an alternative to this fix might be to turn off SCHED_DEBUG, but that appears to have been purposefully turned on so we could implement a feature in the Chrome Browser's Task Manager. See < http://crbug.com/120488 > BUG= chromium:658937 TEST=echo HUNG_TASK > /sys/kernel/debug/provoke-crash/DIRECT Change-Id: I0d99adc02b9a4e93ef0515b9be304f06f20e8edf Fixes: 023068f26f73 ("CHROMIUM: hung_task: dump all UNINTERUPTIBLE tasks") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/404588 Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 73ce7a4bc343eff5df6b125362c5beb9d880bbcb) Reviewed-on: https://chromium-review.googlesource.com/404651 [modify] https://crrev.com/ffb80cede601023ca07727208ab78229193f8e32/kernel/sched/core.c
,
Oct 28 2016
Dan would like M-55 merge for 3.18. We already did for 4.4. I don't think we need merge for 3.14, 3.10, 3.8... We'll just wait for M-56 there.
,
Oct 28 2016
I'd actually like R54, too, since the hung task feedbacks are now useless there too: https://feedback.corp.google.com/product/208/neutron?lView=rd&lReport=14762119537
,
Oct 28 2016
,
Oct 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/27a2b99bf78af87e154bc77e0bf08b2f3fccb562 commit 27a2b99bf78af87e154bc77e0bf08b2f3fccb562 Author: Douglas Anderson <dianders@chromium.org> Date: Thu Oct 27 20:33:03 2016 CHROMIUM: sched: Don't show sched debug when dumping tasks w/ filter On systems with a lot of cores and with a lot of running processes the sysrq_sched_debug_show() call can end up spewing _A LOT_ of data into the debug log. Sometimes you might want all that data, but other times you might not. One case where you might not want all that data is if you were in show_state_filter() called from check_hung_task(). Specifically: - We're probably just about to panic and so logs won't be stored to the filesystem. That means panic info might be going to some sort of persistent RAM (pstore) or a serial console. - If panic info is going to persistent RAM then we probably have limited space, like maybe 128K. - Calling sysrq_sched_debug_show() can very easily blow through 128K of space. - If we blow through the 128K of space then the super important bits printed out by check_hung_task() (the name of the task that is hung plus the stack crawls) will be cut off, rendering the log nearly useless. It seems sane to make show_state_filter() only dump this debug info when the state_filter was 0. When the state_filter is 0 then we're spewing a whole lot of data anyway and so the sched debug info shouldn't hurt. If we're only dumping _some_ of the tasks then presumably we only want info about those tasks and should avoid the extra crud. NOTE: an alternative to this fix might be to turn off SCHED_DEBUG, but that appears to have been purposefully turned on so we could implement a feature in the Chrome Browser's Task Manager. See < http://crbug.com/120488 > BUG= chromium:658937 TEST=echo HUNG_TASK > /sys/kernel/debug/provoke-crash/DIRECT Change-Id: I0d99adc02b9a4e93ef0515b9be304f06f20e8edf Fixes: 023068f26f73 ("CHROMIUM: hung_task: dump all UNINTERUPTIBLE tasks") Signed-off-by: Douglas Anderson <dianders@chromium.org> Previous-Reviewed-on: https://chromium-review.googlesource.com/404588 (cherry picked from commit 73ce7a4bc343eff5df6b125362c5beb9d880bbcb) Previous-Reviewed-on: https://chromium-review.googlesource.com/404033 (cherry picked from commit 582cfad5fc713401021074b1624a260dd33a79c4) Reviewed-on: https://chromium-review.googlesource.com/403676 Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/27a2b99bf78af87e154bc77e0bf08b2f3fccb562/kernel/sched/core.c
,
Oct 28 2016
Still leaving open for M-54 merge request.
,
Oct 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/57e12a71451f6aab788abfedf86034c887cff71f commit 57e12a71451f6aab788abfedf86034c887cff71f Author: Douglas Anderson <dianders@chromium.org> Date: Thu Oct 27 20:33:03 2016 CHROMIUM: sched: Don't show sched debug when dumping tasks w/ filter On systems with a lot of cores and with a lot of running processes the sysrq_sched_debug_show() call can end up spewing _A LOT_ of data into the debug log. Sometimes you might want all that data, but other times you might not. One case where you might not want all that data is if you were in show_state_filter() called from check_hung_task(). Specifically: - We're probably just about to panic and so logs won't be stored to the filesystem. That means panic info might be going to some sort of persistent RAM (pstore) or a serial console. - If panic info is going to persistent RAM then we probably have limited space, like maybe 128K. - Calling sysrq_sched_debug_show() can very easily blow through 128K of space. - If we blow through the 128K of space then the super important bits printed out by check_hung_task() (the name of the task that is hung plus the stack crawls) will be cut off, rendering the log nearly useless. It seems sane to make show_state_filter() only dump this debug info when the state_filter was 0. When the state_filter is 0 then we're spewing a whole lot of data anyway and so the sched debug info shouldn't hurt. If we're only dumping _some_ of the tasks then presumably we only want info about those tasks and should avoid the extra crud. NOTE: an alternative to this fix might be to turn off SCHED_DEBUG, but that appears to have been purposefully turned on so we could implement a feature in the Chrome Browser's Task Manager. See < http://crbug.com/120488 > BUG= chromium:658937 TEST=echo HUNG_TASK > /sys/kernel/debug/provoke-crash/DIRECT Change-Id: I0d99adc02b9a4e93ef0515b9be304f06f20e8edf Fixes: 023068f26f73 ("CHROMIUM: hung_task: dump all UNINTERUPTIBLE tasks") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/404588 Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 73ce7a4bc343eff5df6b125362c5beb9d880bbcb) Reviewed-on: https://chromium-review.googlesource.com/404749 [modify] https://crrev.com/57e12a71451f6aab788abfedf86034c887cff71f/kernel/sched/core.c
,
Oct 30 2016
[Automated comment] Request affecting a post-stable build (M54), manual review required.
,
Dec 12 2016
No way this is going to be merged to M54 at this point. Closing.
,
Jan 13 2017
,
Mar 14 2017
This regressed on kernel 4.4 due to an accidental revert of the important patch. See <https://chromium-review.googlesource.com/c/419668/> Re-opening. Probably too late for R57, so targeting R58.
,
Mar 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/41fb683c94eb9d0d38d6bd0ce04b39ab58bae2fd commit 41fb683c94eb9d0d38d6bd0ce04b39ab58bae2fd Author: Douglas Anderson <dianders@chromium.org> Date: Wed Mar 15 00:10:01 2017 CHROMIUM: sched: Don't show sched debug when dumping tasks w/ filter (redux) On systems with a lot of cores and with a lot of running processes the sysrq_sched_debug_show() call can end up spewing _A LOT_ of data into the debug log. Sometimes you might want all that data, but other times you might not. One case where you might not want all that data is if you were in show_state_filter() called from check_hung_task(). Specifically: - We're probably just about to panic and so logs won't be stored to the filesystem. That means panic info might be going to some sort of persistent RAM (pstore) or a serial console. - If panic info is going to persistent RAM then we probably have limited space, like maybe 128K. - Calling sysrq_sched_debug_show() can very easily blow through 128K of space. - If we blow through the 128K of space then the super important bits printed out by check_hung_task() (the name of the task that is hung plus the stack crawls) will be cut off, rendering the log nearly useless. It seems sane to make show_state_filter() only dump this debug info when the state_filter was 0. When the state_filter is 0 then we're spewing a whole lot of data anyway and so the sched debug info shouldn't hurt. If we're only dumping _some_ of the tasks then presumably we only want info about those tasks and should avoid the extra crud. NOTE: an alternative to this fix might be to turn off SCHED_DEBUG, but that appears to have been purposefully turned on so we could implement a feature in the Chrome Browser's Task Manager. See < http://crbug.com/120488 > BUG= chromium:658937 TEST=echo HUNG_TASK > /sys/kernel/debug/provoke-crash/DIRECT NOTE: original task was accidentally reverted. Redoing. Orig-Change-Id: I0d99adc02b9a4e93ef0515b9be304f06f20e8edf Fixes: 023068f26f73 ("CHROMIUM: hung_task: dump all UNINTERUPTIBLE tasks") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/404588 Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 73ce7a4bc343eff5df6b125362c5beb9d880bbcb) Change-Id: Ia0bc1fca85f0143104753b80b4816ee87ab262ba Reviewed-on: https://chromium-review.googlesource.com/454249 Commit-Ready: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Reviewed-by: Sonny Rao <sonnyrao@chromium.org> [modify] https://crrev.com/41fb683c94eb9d0d38d6bd0ce04b39ab58bae2fd/kernel/sched/core.c
,
Mar 15 2017
Above change matches the behavior for older builds and effectively undoes the revert, thus this is well tested. Author of the revert says it was not an intentional revert. Requesting merge to M-58.
,
Mar 16 2017
Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1adbd328a7c0f3e9414fff706b376d58496e9ea4 commit 1adbd328a7c0f3e9414fff706b376d58496e9ea4 Author: Douglas Anderson <dianders@chromium.org> Date: Thu Mar 16 16:11:20 2017 CHROMIUM: sched: Don't show sched debug when dumping tasks w/ filter (redux) On systems with a lot of cores and with a lot of running processes the sysrq_sched_debug_show() call can end up spewing _A LOT_ of data into the debug log. Sometimes you might want all that data, but other times you might not. One case where you might not want all that data is if you were in show_state_filter() called from check_hung_task(). Specifically: - We're probably just about to panic and so logs won't be stored to the filesystem. That means panic info might be going to some sort of persistent RAM (pstore) or a serial console. - If panic info is going to persistent RAM then we probably have limited space, like maybe 128K. - Calling sysrq_sched_debug_show() can very easily blow through 128K of space. - If we blow through the 128K of space then the super important bits printed out by check_hung_task() (the name of the task that is hung plus the stack crawls) will be cut off, rendering the log nearly useless. It seems sane to make show_state_filter() only dump this debug info when the state_filter was 0. When the state_filter is 0 then we're spewing a whole lot of data anyway and so the sched debug info shouldn't hurt. If we're only dumping _some_ of the tasks then presumably we only want info about those tasks and should avoid the extra crud. NOTE: an alternative to this fix might be to turn off SCHED_DEBUG, but that appears to have been purposefully turned on so we could implement a feature in the Chrome Browser's Task Manager. See < http://crbug.com/120488 > BUG= chromium:658937 TEST=echo HUNG_TASK > /sys/kernel/debug/provoke-crash/DIRECT NOTE: original task was accidentally reverted. Redoing. Orig-Change-Id: I0d99adc02b9a4e93ef0515b9be304f06f20e8edf Fixes: 023068f26f73 ("CHROMIUM: hung_task: dump all UNINTERUPTIBLE tasks") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/404588 Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 73ce7a4bc343eff5df6b125362c5beb9d880bbcb) Change-Id: Ia0bc1fca85f0143104753b80b4816ee87ab262ba Reviewed-on: https://chromium-review.googlesource.com/454249 Commit-Ready: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Reviewed-by: Sonny Rao <sonnyrao@chromium.org> (cherry picked from commit 41fb683c94eb9d0d38d6bd0ce04b39ab58bae2fd) Reviewed-on: https://chromium-review.googlesource.com/456476 Reviewed-by: Douglas Anderson <dianders@chromium.org> [modify] https://crrev.com/1adbd328a7c0f3e9414fff706b376d58496e9ea4/kernel/sched/core.c
,
Mar 16 2017
Fixed again in R58. ...so I think R56 and R57 are the broken ones, but not going to go back and pick to there now I think...
,
Mar 16 2017
Ketaki: I think this change might be worth doing as a late pick to M-57. I'm seeing a big uptick in hung tasks in feedback reports on Kevin and they are not debuggable without the above fix.
,
Mar 17 2017
Approving merge to M57 Chrome OS.
,
Mar 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/cc8db8e2246ed14789acb184733ed4549018163c commit cc8db8e2246ed14789acb184733ed4549018163c Author: Douglas Anderson <dianders@chromium.org> Date: Fri Mar 17 17:28:03 2017 CHROMIUM: sched: Don't show sched debug when dumping tasks w/ filter On systems with a lot of cores and with a lot of running processes the sysrq_sched_debug_show() call can end up spewing _A LOT_ of data into the debug log. Sometimes you might want all that data, but other times you might not. One case where you might not want all that data is if you were in show_state_filter() called from check_hung_task(). Specifically: - We're probably just about to panic and so logs won't be stored to the filesystem. That means panic info might be going to some sort of persistent RAM (pstore) or a serial console. - If panic info is going to persistent RAM then we probably have limited space, like maybe 128K. - Calling sysrq_sched_debug_show() can very easily blow through 128K of space. - If we blow through the 128K of space then the super important bits printed out by check_hung_task() (the name of the task that is hung plus the stack crawls) will be cut off, rendering the log nearly useless. It seems sane to make show_state_filter() only dump this debug info when the state_filter was 0. When the state_filter is 0 then we're spewing a whole lot of data anyway and so the sched debug info shouldn't hurt. If we're only dumping _some_ of the tasks then presumably we only want info about those tasks and should avoid the extra crud. NOTE: an alternative to this fix might be to turn off SCHED_DEBUG, but that appears to have been purposefully turned on so we could implement a feature in the Chrome Browser's Task Manager. See < http://crbug.com/120488 > BUG= chromium:658937 TEST=echo HUNG_TASK > /sys/kernel/debug/provoke-crash/DIRECT Change-Id: I0d99adc02b9a4e93ef0515b9be304f06f20e8edf Fixes: 023068f26f73 ("CHROMIUM: hung_task: dump all UNINTERUPTIBLE tasks") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/404588 Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 73ce7a4bc343eff5df6b125362c5beb9d880bbcb) Reviewed-on: https://chromium-review.googlesource.com/456919 [modify] https://crrev.com/cc8db8e2246ed14789acb184733ed4549018163c/kernel/sched/core.c
,
Mar 17 2017
OK, landed. So the only version that's hard to debug will be M-56. ;)
,
Mar 17 2017
,
May 23 2017
Does this need to land in 59?
,
May 23 2017
No. The fix landed in R59 and was picked back to R57 and R58.
,
Jun 16 2017
,
Jan 22 2018
|
|||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||
Comment 1 by diand...@chromium.org
, Oct 27 2016