On Thu, May 01, 2008 at 03:05:19PM -0600, Matthew Wilcox wrote:
> On Thu, May 01, 2008 at 11:40:37PM +0300, Adrian Bunk wrote:
> > On Thu, May 01, 2008 at 02:25:33PM -0600, Matthew Wilcox wrote:
> > > However, the code is not buggy. Just compare:
> > >
> > > vma = vma_tmp;
> > > if (vma_tmp->vm_start <= addr)
> > > return vma;
> > >
> > > with
> > >
> > > munmap_back:
> > > vma = find_vma_prepare(mm, addr, &prev, &rb_link, &rb_parent);
> > > if (vma && vma->vm_start < addr + len) {
> > > if (do_munmap(mm, addr, len))
> > > return -ENOMEM;
> > > goto munmap_back;
> > > }
> > >
> > > Now, we know that addr + len does not wrap, and that len > 0, so we know
> > > that this warning is incorrect. But it's not reasonable to expect gcc to
> > > be able to deduce this.
> > >...
> >
> > Can you submit a patch with your explanation that uses
> > uninitialized_var() to silence these warnings?
>
> I could, but I don't know if I want to. Suppose somebody changes the
> code later to actually make prev used before it's initialised? Then we
> would have GCC not warning about a problem.
That's why we silence the warnings with uninitialized_var() - simply
change the #define and you'll see all silenced warnings.
The problem is that these warnings for which we know that the code is OK
today make it harder to spot where new warnings get added that might
indicate real bugs.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
