linux-kernel - Re: [PATCH] rcu: change function declaration to bool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20150511151901.GA17629@opentech.at>
Date:	Mon, 11 May 2015 17:19:01 +0200
From:	Nicholas Mc Guire <der.herr@...r.at>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	Nicholas Mc Guire <hofrat@...dl.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rcu: change function declaration to bool

On Mon, 11 May 2015, Josh Triplett wrote:

> On Mon, May 11, 2015 at 10:51:55AM +0200, Nicholas Mc Guire wrote:
> > rcu_cpu_has_callbacks() is declared int but is actually returning bool and
> > all call-sites currently use it as bool so the declaration should be bool 
> > as well.
> > 
> > Signed-off-by: Nicholas Mc Guire <hofrat@...dl.org>
> 
> The patch seems reasonable to me.  However...
> 
> > ---
> > 
> > ./kernel/rcu/tree.c:3538 WARNING: return of wrong type
> >                     int != bool, 
> > 
> > as the description of rcu_cpu_has_callbacks() states:
> > " * Return true if the specified CPU has any callback...."
> > this probably should be a bool 
> > All (3) call sites are conditions and are treating it as boolean.
> > 
> > Patch was compile tested with x86_64_defconfig (implies CONFIG_TREE_RCU=y)
> 
> ...some of this information should be in the commit message, as well as
> a description of what tool produced this warning.
>

The tool is coccinelle - type checking scripts that Im working on and that
produced (with Julia Lawal fixing up my .cocci scripts) a few 1000s of 
type missmatches in the overall kernel a few hundred in the ./kernel/* - 
so starting to clean up....
 
> With that changed,
> Reviewed-by: Josh Triplett <josh@...htriplett.org>
>

thanks - just resend with description moved. and a note that coccinelle was
used.

The full script is though in its current form not yet usable as it is not 
classifying type errors - had to do that manually - for the kernel (and 
glibc for comparison) this is currently:

component  Nr funcs  != type    %
kernel   :  374600    10727    2.85
glibc    :    9184      268    2.92

finding                  kernel  glibc 
wrong ?                :     8     4   
sign missmatch         :  2279    30   
down sized             :   435    49   
up sized               :   910    20   
declaration missmatch  :  7095   165   

as noted - sorting/filtering needed some manual work so nubers
are not that precise. wrong here simply means I could not figure
it out like an int foo() returning a float.

Once this is cleaned up I'll post the type-checking scripts along with
the depressing results...

// Find functions where return type and signature do not match
// V2: with the suggestions/improvements from Julia Lawal added this
// now finds about 10 times as many bad cases ...                               
//
// Comments:
// Options: --no-includes --include-headers

virtual context
virtual org
virtual report

@match exists@
type T1,T2;
idexpression T1 ok;
idexpression T2 ret;
identifier f;
constant C;
position p;
@@

T1 f(...) {
<+...
(
return ok;
|
return C;
|
return@p ret;
)
...+>
}

@script:python@
p << match.p;
fn << match.f;
T1 << match.T1;
T2 << match.T2;
@@

print "%s:%s WARNING: return of wrong type \n\t %s != %s" % (p[0].file,p[0].line,T1,T2)
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/