lkml.org 
[lkml]   [2009]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] oom: dump stack and VM state when oom killer panics
On Thu, 17 Sep 2009 13:55:22 -0700 (PDT)
David Rientjes <rientjes@google.com> wrote:

> The oom killer header, including information such as the allocation order
> and gfp mask, current's cpuset and memory controller, call trace, and VM
> state information is currently only shown when the oom killer has
> selected a task to kill.
>
> This information is omitted, however, when the oom killer panics either
> because of panic_on_oom sysctl settings or when no killable task was
> found. It is still relevant to know crucial pieces of information such
> as the allocation order and VM state when diagnosing such issues,
> especially at boot.
>
> This patch displays the oom killer header whenever it panics so that bug
> reports can include pertinent information to debug the issue, if
> possible.
>
> Signed-off-by: David Rientjes <rientjes@google.com>

Seems nice.
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>


> ---
> mm/oom_kill.c | 45 +++++++++++++++++++++++++++------------------
> 1 files changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -310,6 +310,23 @@ static void dump_tasks(const struct mem_cgroup *mem)
> } while_each_thread(g, p);
> }
>
> +static void dump_header(gfp_t gfp_mask, int order, struct mem_cgroup *mem)
> +{
> + if (printk_ratelimit()) {
> + printk(KERN_WARNING "%s invoked oom-killer: "
> + "gfp_mask=0x%x, order=%d, oomkilladj=%d\n",
> + current->comm, gfp_mask, order, current->oomkilladj);
> + task_lock(current);
> + cpuset_print_task_mems_allowed(current);
> + task_unlock(current);
> + dump_stack();
> + mem_cgroup_print_oom_info(mem, current);
> + show_mem();
> + if (sysctl_oom_dump_tasks)
> + dump_tasks(mem);
> + }
> +}
> +
> /*
> * Send SIGKILL to the selected process irrespective of CAP_SYS_RAW_IO
> * flag though it's unlikely that we select a process with CAP_SYS_RAW_IO
> @@ -392,20 +409,7 @@ static int oom_kill_process(struct task_struct *p, gfp_t gfp_mask, int order,
> {
> struct task_struct *c;
>
> - if (printk_ratelimit()) {
> - printk(KERN_WARNING "%s invoked oom-killer: "
> - "gfp_mask=0x%x, order=%d, oomkilladj=%d\n",
> - current->comm, gfp_mask, order, current->oomkilladj);
> - task_lock(current);
> - cpuset_print_task_mems_allowed(current);
> - task_unlock(current);
> - dump_stack();
> - mem_cgroup_print_oom_info(mem, current);
> - show_mem();
> - if (sysctl_oom_dump_tasks)
> - dump_tasks(mem);
> - }
> -
> + dump_header(gfp_mask, order, mem);
> /*
> * If the task is already exiting, don't alarm the sysadmin or kill
> * its children or threads, just set TIF_MEMDIE so it can die quickly
> @@ -540,6 +544,7 @@ retry:
> /* Found nothing?!?! Either we hang forever, or we panic. */
> if (!p) {
> read_unlock(&tasklist_lock);
> + dump_header(gfp_mask, order, NULL);
> panic("Out of memory and no killable processes...\n");
> }
>
> @@ -605,8 +610,10 @@ void out_of_memory(struct zonelist *zonelist, gfp_t gfp_mask, int order)
> /* Got some memory back in the last second. */
> return;
>
> - if (sysctl_panic_on_oom == 2)
> - panic("out of memory. Compulsory panic_on_oom is selected.\n");
> + if (sysctl_panic_on_oom == 2) {
> + dump_header(gfp_mask, order, NULL);
> + panic("Out of memory. Compulsory panic_on_oom is selected.\n");
> + }
>
> /*
> * Check if there were limitations on the allocation (only relevant for
> @@ -622,8 +629,10 @@ void out_of_memory(struct zonelist *zonelist, gfp_t gfp_mask, int order)
> break;
>
> case CONSTRAINT_NONE:
> - if (sysctl_panic_on_oom)
> - panic("out of memory. panic_on_oom is selected\n");
> + if (sysctl_panic_on_oom) {
> + dump_header(gfp_mask, order, NULL);
> + panic("Out of memory. panic_on_oom is selected.\n");
> + }
> /* Fall-through */
> case CONSTRAINT_CPUSET:
> __out_of_memory(gfp_mask, order);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>



\
 
 \ /
  Last update: 2009-09-18 02:27    [W:0.055 / U:0.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site