Re: + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree

Re: + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree

[David Rientjes]

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

Re: + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree

[Hugh Dickins]

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

Re: + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree

[David Rientjes]

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?

Re: + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree

[Hugh Dickins]

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) {

Re: + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree

[David Rientjes]

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>

Re: + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree

[Hugh Dickins]

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