Re: [PATCH] mm, debug: mm-introduce-vm_bug_on_mm-fix-fix.patch

[Michal Hocko]

On Mon 13-10-14 14:51:56, Dave Jones wrote:
[...]
> diff --git a/mm/debug.c b/mm/debug.c
> index 5ce45c9a29b5..e04e2ae902a1 100644
> --- a/mm/debug.c
> +++ b/mm/debug.c
> @@ -164,74 +164,85 @@ void dump_vma(const struct vm_area_struct *vma)
>  }
>  EXPORT_SYMBOL(dump_vma);
>  
> +static char dumpmm_buffer[4096];
> +
>  void dump_mm(const struct mm_struct *mm)
>  {
> -	pr_emerg("mm %p mmap %p seqnum %d task_size %lu\n"
> -#ifdef CONFIG_MMU
> -		"get_unmapped_area %p\n"
> -#endif
> -		"mmap_base %lu mmap_legacy_base %lu highest_vm_end %lu\n"
> -		"pgd %p mm_users %d mm_count %d nr_ptes %lu map_count %d\n"
> -		"hiwater_rss %lx hiwater_vm %lx total_vm %lx locked_vm %lx\n"
> -		"pinned_vm %lx shared_vm %lx exec_vm %lx stack_vm %lx\n"
> -		"start_code %lx end_code %lx start_data %lx end_data %lx\n"
> -		"start_brk %lx brk %lx start_stack %lx\n"
> -		"arg_start %lx arg_end %lx env_start %lx env_end %lx\n"
> -		"binfmt %p flags %lx core_state %p\n"
> -#ifdef CONFIG_AIO
> -		"ioctx_table %p\n"
> -#endif
> -#ifdef CONFIG_MEMCG
> -		"owner %p "
> -#endif
> -		"exe_file %p\n"
> -#ifdef CONFIG_MMU_NOTIFIER
> -		"mmu_notifier_mm %p\n"
> -#endif
> -#ifdef CONFIG_NUMA_BALANCING
> -		"numa_next_scan %lu numa_scan_offset %lu numa_scan_seq %d\n"
> -#endif
> -#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION)
> -		"tlb_flush_pending %d\n"
> -#endif
> -		"%s",	/* This is here to hold the comma */
> +	char *p = dumpmm_buffer;
> +
> +	memset(dumpmm_buffer, 0, 4096);

I do not see any locking here. Previously we had internal printk log as
a natural synchronization. Now two threads are allowed to scribble over
their messages leaving an unusable output in a better case.

Besides that the %s with "" trick is not really that ugly and handles
the situation quite nicely. So do we really want to make it more
complicated?
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/