* Re: + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree
[not found] <20120816200105.C14EA1E0048@wpzn4.hot.corp.google.com>
@ 2012-09-11 17:55 ` David Rientjes
2012-09-11 18:24 ` Hugh Dickins
0 siblings, 1 reply; 6+ messages in thread
From: David Rientjes @ 2012-09-11 17:55 UTC (permalink / raw)
To: linux-kernel; +Cc: mm-commits, hughd, bhalevy, dhillf
On Thu, 16 Aug 2012, akpm@linux-foundation.org wrote:
>
> The patch titled
> Subject: mm/mmap.c: replace find_vma_prepare() with clearer find_vma_links()
> has been added to the -mm tree. Its filename is
> mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch
>
> Before you just go and hit "reply", please:
> a) Consider who else should be cc'ed
> b) Prefer to cc a suitable mailing list as well
> c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
>
> ------------------------------------------------------
> From: Hugh Dickins <hughd@google.com>
> Subject: mm/mmap.c: replace find_vma_prepare() with clearer find_vma_links()
>
> People get confused by find_vma_prepare(), because it doesn't care about
> what it returns in its output args, when its callers won't be interested.
>
> Clarify by passing in end-of-range address too, and returning failure if
> any existing vma overlaps the new range: instead of returning an ambiguous
> vma which most callers then must check. find_vma_links() is a clearer
> name.
>
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree
2012-09-11 17:55 ` + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree David Rientjes
@ 2012-09-11 18:24 ` Hugh Dickins
2012-09-12 1:44 ` David Rientjes
0 siblings, 1 reply; 6+ messages in thread
From: Hugh Dickins @ 2012-09-11 18:24 UTC (permalink / raw)
To: David Rientjes; +Cc: linux-kernel, mm-commits, bhalevy, dhillf
On Tue, 11 Sep 2012, David Rientjes wrote:
> On Thu, 16 Aug 2012, akpm@linux-foundation.org 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.
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.
Hugh
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree
2012-09-11 18:24 ` Hugh Dickins
@ 2012-09-12 1:44 ` David Rientjes
2012-09-12 18:52 ` Hugh Dickins
0 siblings, 1 reply; 6+ messages in thread
From: David Rientjes @ 2012-09-12 1:44 UTC (permalink / raw)
To: Hugh Dickins; +Cc: linux-kernel, mm-commits, bhalevy, dhillf
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/*.
> 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() that we can't fix it all up to use
uninitialized_var() so this is handled the proper way? If CONFIG_BUG
exists, then we should support it, right?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree
2012-09-12 1:44 ` David Rientjes
@ 2012-09-12 18:52 ` Hugh Dickins
2012-09-12 23:25 ` David Rientjes
0 siblings, 1 reply; 6+ messages in thread
From: Hugh Dickins @ 2012-09-12 18:52 UTC (permalink / raw)
To: David Rientjes; +Cc: Andrew Morton, linux-kernel, mm-commits, bhalevy, dhillf
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 <hughd@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) {
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree
2012-09-12 18:52 ` Hugh Dickins
@ 2012-09-12 23:25 ` David Rientjes
2012-09-12 23:53 ` Hugh Dickins
0 siblings, 1 reply; 6+ messages in thread
From: David Rientjes @ 2012-09-12 23:25 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Andrew Morton, linux-kernel, mm-commits, bhalevy, dhillf
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree
2012-09-12 23:25 ` David Rientjes
@ 2012-09-12 23:53 ` Hugh Dickins
0 siblings, 0 replies; 6+ messages in thread
From: Hugh Dickins @ 2012-09-12 23:53 UTC (permalink / raw)
To: David Rientjes; +Cc: Andrew Morton, linux-kernel, mm-commits, bhalevy, dhillf
On Wed, 12 Sep 2012, David Rientjes wrote:
> 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'm not necessarily against __maybe_unused, but I am surprised that it
should have an effect here: I think of that as a tool for a different
job, and would be misleading in this context.
> > 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>
Thanks!
Hugh
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-09-12 23:54 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20120816200105.C14EA1E0048@wpzn4.hot.corp.google.com>
2012-09-11 17:55 ` + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree David Rientjes
2012-09-11 18:24 ` Hugh Dickins
2012-09-12 1:44 ` David Rientjes
2012-09-12 18:52 ` Hugh Dickins
2012-09-12 23:25 ` David Rientjes
2012-09-12 23:53 ` Hugh Dickins
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).