[lkml]   [2012]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree
On Wed, 12 Sep 2012, Hugh Dickins wrote:

> > that we can't fix it all up to use
> > uninitialized_var() so this is handled the proper way?
> I do prefer to avoid it when we can, some reasons given below.

It's easily silenced with __maybe_unused. I advocated for using that
attribute for unusued labels in mm/slab_common.c as well where we now do
things like


repeatedly, but others felt this was better than simply doing

out: __maybe_unused

Not sure what your preferences are for just adding __maybe_unused to the

> > If CONFIG_BUG exists, then we should support it, right?
> Up to a point, yes: we don't encourage switching it off ("Just say Y").
> I'm reluctant to add a notation just for this discouraged case, but how
> how about this patch - does it actually fix the warning you see, David?
> [PATCH mmotm] mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links fix
> Strangely, I can no longer get an uninitialized variable warning out of
> copy_vma(), with or without the BUG() there; but David Rientjes gets it
> when he builds with CONFIG_BUG off, which is understandable.
> uninitialized_var() can be a useful tool, but I do prefer to avoid it:
> partly because it might hide future errors, partly because I misspell
> it, but mainly because the need for it comes and goes so mysteriously.
> Given David's preference for no warning, mine for no uninitialized_var,
> and Linus's for renaming BUG() to I_AM_A_MORON() to discourage its use
> in the first place: copy_vma() seems a prime candidate for returning
> failure to mremap instead of crashing the system.
> Signed-off-by: Hugh Dickins <>

Tested-by: David Rientjes <>

 \ /
  Last update: 2012-09-13 01:41    [W:0.076 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site