On Tue, 11 Sep 2012, David Rientjes wrote:
> On Tue, 11 Sep 2012, Hugh Dickins wrote:
>
> > > > This does revert 2.6.27's dfe195fb79e88 ("mm: fix uninitialized
> > > > variables
> > > > for find_vma_prepare callers"), but it looks like gcc 4.3.0 was one of
> > > > those releases too eager to shout about uninitialized variables: only
> > > > copy_vma() warns with 4.5.1 and 4.7.1, which a BUG on error silences.
> > > >
> > >
> > > That trick doesn't work if CONFIG_BUG=n.
> > >
> > > mm/mmap.c: In function 'copy_vma':
> > > mm/mmap.c:2344: warning: 'prev' may be used uninitialized in this function
> > > mm/mmap.c:2345: warning: 'rb_link' may be used uninitialized in this
> > > function
> > > mm/mmap.c:2345: warning: 'rb_parent' may be used uninitialized in this
> > > function
> >
> > Hmm, right: not an option I ever choose, and I hadn't given it a thought.
> >
> > But do we care? If this introduced the only such warning, I would care.
>
> It now has the distinction of being the only warning for CONFIG_BUG=n in
> mm/*.
You're tempting me to ask "Hey, what's so special about mm/ ?" ;)
No, but seriously, I do share your pride in keeping mm/ clean.
>
> > But that seems to be far from the case - building my usual config without
> > CONFIG_BUG gives me 36 warnings, of uninitialized and unused and
> > control reaches end of non-void varieties.
> >
>
> What's so special about copy_vma()
I don't know: why does copy_vma() give a warning but __insert_vm_struct()
not? Rhetorical question, I don't expect an answer, but suspect it's
some accident of inlining, or how hard gcc has to try to work it out.
What I didn't notice yesterday when I reported 36 warnings with CONFIG_BUG
off, is that for me mm/mmap.c was not amongst them: and doesn't warn now
if I remove the BUG, although obviously it did before I added the BUG.
> 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.
> 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 <hu...@google.com>
---
mm/mmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- mmotm/mm/mmap.c 2012-09-07 12:39:38.124019726 -0700
+++ linux/mm/mmap.c 2012-09-12 11:11:51.340174537 -0700
@@ -2356,7 +2356,7 @@ struct vm_area_struct *copy_vma(struct v
}
if (find_vma_links(mm, addr, addr + len, &prev, &rb_link, &rb_parent))
- BUG();
+ return NULL; /* should never get here */
new_vma = vma_merge(mm, prev, addr, addr + len, vma->vm_flags,
vma->anon_vma, vma->vm_file, pgoff, vma_policy(vma));
if (new_vma) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
