Messages in this thread | | | Date | Wed, 12 Sep 2012 16:25:23 -0700 (PDT) | From | David Rientjes <> | Subject | Re: + 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
#ifdef CONFIG_DEBUG_SLAB out: #endif
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 declaration.
> > 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 <hughd@google.com>
Tested-by: David Rientjes <rientjes@google.com>
| |