Re: [PATCH] fix sparse happy borkage when including gfp.h

Re: [PATCH] fix sparse happy borkage when including gfp.h

[Dave Hansen]

On Fri, 2011-04-15 at 14:33 +0900, KOSAKI Motohiro wrote:
> Hello,
> > On Fri, 2011-04-15 at 12:14 +0900, KOSAKI Motohiro wrote:
> > > >  #ifdef CONFIG_DEBUG_VM
> > > > -             BUG_ON((GFP_ZONE_BAD >> bit) & 1);
> > > > +     BUG_ON((GFP_ZONE_BAD >> bit) & 1);
> > > >  #endif
> > > > -     }
> > > >       return z;
> > > 
> > > Why don't you use VM_BUG_ON?
> > 
> > I was just trying to make a minimal patch that did a single thing.
> > 
> > Feel free to submit another one that does that.  I'm sure there are a
> > couple more places that could use similar love.
> 
> I posted another approach patches a second ago. Could you please see it?

Those both look sane to me.  Those weren't biting me in particular, and
they don't fix the issue I was seeing.  But, they do seem necessary to
reduce some of the noise.

CC'ing the sparse mailing list.  We're seeing a couple of cases where
some gcc-isms are either stopping sparse from finding real bugs:

	http://marc.info/?l=linux-mm&m=130282454732689&w=2

or creating a lot of noise on some builds:

	http://marc.info/?l=linux-mm&m=130284428614058&w=2
	http://marc.info/?l=linux-mm&m=130284431014077&w=2

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] fix sparse happy borkage when including gfp.h

[Christopher Li]

On Fri, Apr 15, 2011 at 7:27 AM, Dave Hansen <dave@linux.vnet.ibm.com> wrote:
> Those both look sane to me.  Those weren't biting me in particular, and
> they don't fix the issue I was seeing.  But, they do seem necessary to
> reduce some of the noise.
>
> CC'ing the sparse mailing list.  We're seeing a couple of cases where
> some gcc-isms are either stopping sparse from finding real bugs:
>
>        http://marc.info/?l=linux-mm&m=130282454732689&w=2

I take a look at this problem. The bug can be simplify as the following source:

typedef unsigned __attribute__((bitwise)) gfp_t;

void foo ( gfp_t flags)
{
	int bit = (__attribute__((force)) int) (flags &
(((__attribute__((force)) gfp_t)0x01u)|((__attribute__((force))
gfp_t)0x02u)|((__attribute__((force))
gfp_t)0x04u)|((__attribute__((force)) gfp_t)0x08u)));

	if (__builtin_constant_p(bit))
			((void)sizeof(char[1 - 2 * !!((( 1 << (0x01u | 0x02u) | 1 << (0x01u
| 0x04u) | 1 << (0x04u | 0x02u) | 1 << (0x01u | 0x04u | 0x02u) | 1 <<
(0x08u | 0x02u | 0x01u) | 1 << (0x08u | 0x04u | 0x01u) | 1 << (0x08u |
0x04u | 0x02u) | 1 << (0x08u | 0x04u | 0x01u | 0x02u) ) >> bit) &
1)]));
}

Sparse chock on variable length array. It is nothing new. It was
useful to warn about
the variable length array usage in the kernel, because it might
overflow the kernel stack.
In this case, it is just a clever trick to issue assert on compile time.

We should bite the bullet and just parse the variable length array as
expression. We can still issue
warning for non constant usage, without the early bail out from sparse.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html