[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <541223F9.2090500@oracle.com>
Date: Thu, 11 Sep 2014 18:36:41 -0400
From: Sasha Levin <sasha.levin@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: kirill.shutemov@...ux.intel.com, khlebnikov@...nvz.org,
riel@...hat.com, mgorman@...e.de, n-horiguchi@...jp.nec.com,
mhocko@...e.cz, hughd@...gle.com, vbabka@...e.cz,
walken@...gle.com, minchan@...nel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 2/3] mm: introduce VM_BUG_ON_MM
On 09/11/2014 05:16 PM, Andrew Morton wrote:
> On Sat, 6 Sep 2014 15:38:45 -0400 Sasha Levin <sasha.levin@...cle.com> wrote:
>
>> Very similar to VM_BUG_ON_PAGE and VM_BUG_ON_VMA, dump struct_mm
>> when the bug is hit.
>>
>> ...
>>
>> +void dump_mm(const struct mm_struct *mm)
>> +{
>> + printk(KERN_ALERT
>
> I'm not sure why we should use KERN_ALERT here - KERN_EMERG is for
> "system is unusable", which is a fair descrition of a post-BUG kernel,
> yes?
Yes. I was following suit with dump_page and assumed there's a good reasoning
behind KERN_ALERT.
>> + "mm %p mmap %p seqnum %d task_size %lu\n"
>> +#ifdef CONFIG_MMU
>> + "get_unmapped_area %p\n"
>> +#endif
>
> This printk is rather hilarious. I can't think of a better way apart
> from a great string of individual printks.
>
> And maybe we should use individual printks - dump_mm() presently uses
> 114 bytes of stack for that printk and that's somewhat of a concern
> considering the situations when it will be called.
>
>
> How's this look?
Works for me.
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists