rcu_cpu_has_callbacks() is declared int but is actually returning bool and
and as the function description states " * Return true if the specified
CPU has any callback....", this probably should be a bool. All (3)
call-sites currently treat it as bool so the declaration.
Signed-off-by: Nicholas Mc Guire <[email protected]>
---
V2: fixed up commit message and tool infos as requested by
Josh Triplett <[email protected]>
Type-checking coccinelle spatches are being used to locate type
mismatches between function signatures and return values.
./kernel/rcu/tree.c:3538 WARNING: return of wrong type
int != bool,
Patch was compile tested with x86_64_defconfig (implies CONFIG_TREE_RCU=y)
Patch is against 4.1-rc3 (localversion-next is -next-20150511)
kernel/rcu/tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index bcc5943..599550c 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3516,7 +3516,7 @@ static int rcu_pending(void)
* non-NULL, store an indication of whether all callbacks are lazy.
* (If there are no callbacks, all of them are deemed to be lazy.)
*/
-static int __maybe_unused rcu_cpu_has_callbacks(bool *all_lazy)
+static bool __maybe_unused rcu_cpu_has_callbacks(bool *all_lazy)
{
bool al = true;
bool hc = false;
--
1.7.10.4
On Mon, 11 May 2015 17:10:59 +0200
Nicholas Mc Guire <[email protected]> wrote:
> rcu_cpu_has_callbacks() is declared int but is actually returning bool and
> and as the function description states " * Return true if the specified
> CPU has any callback....", this probably should be a bool. All (3)
> call-sites currently treat it as bool so the declaration.
>
>
> Signed-off-by: Nicholas Mc Guire <[email protected]>
> ---
>
> V2: fixed up commit message and tool infos as requested by
> Josh Triplett <[email protected]>
>
> Type-checking coccinelle spatches are being used to locate type
> mismatches between function signatures and return values.
> ./kernel/rcu/tree.c:3538 WARNING: return of wrong type
> int != bool,
>
> Patch was compile tested with x86_64_defconfig (implies CONFIG_TREE_RCU=y)
>
> Patch is against 4.1-rc3 (localversion-next is -next-20150511)
I think what Josh was saying is that all the above except for the "V2"
should be above the signature. Everything between the "---" and the
patch gets tossed out when committed into git.
Giving credit to coccinelle and even what branch and config was used
for testing is something we want in the git change log history.
-- Steve
>
> kernel/rcu/tree.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index bcc5943..599550c 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -3516,7 +3516,7 @@ static int rcu_pending(void)
> * non-NULL, store an indication of whether all callbacks are lazy.
> * (If there are no callbacks, all of them are deemed to be lazy.)
> */
> -static int __maybe_unused rcu_cpu_has_callbacks(bool *all_lazy)
> +static bool __maybe_unused rcu_cpu_has_callbacks(bool *all_lazy)
> {
> bool al = true;
> bool hc = false;
On Mon, May 11, 2015 at 11:28:30AM -0400, Steven Rostedt wrote:
> On Mon, 11 May 2015 17:10:59 +0200
> Nicholas Mc Guire <[email protected]> wrote:
>
> > rcu_cpu_has_callbacks() is declared int but is actually returning bool and
> > and as the function description states " * Return true if the specified
> > CPU has any callback....", this probably should be a bool. All (3)
> > call-sites currently treat it as bool so the declaration.
> >
> >
> > Signed-off-by: Nicholas Mc Guire <[email protected]>
> > ---
> >
> > V2: fixed up commit message and tool infos as requested by
> > Josh Triplett <[email protected]>
> >
> > Type-checking coccinelle spatches are being used to locate type
> > mismatches between function signatures and return values.
> > ./kernel/rcu/tree.c:3538 WARNING: return of wrong type
> > int != bool,
> >
> > Patch was compile tested with x86_64_defconfig (implies CONFIG_TREE_RCU=y)
> >
> > Patch is against 4.1-rc3 (localversion-next is -next-20150511)
>
> I think what Josh was saying is that all the above except for the "V2"
> should be above the signature. Everything between the "---" and the
> patch gets tossed out when committed into git.
>
> Giving credit to coccinelle and even what branch and config was used
> for testing is something we want in the git change log history.
Yes, exactly.
- Josh Triplett
On Mon, 11 May 2015, Josh Triplett wrote:
> On Mon, May 11, 2015 at 11:28:30AM -0400, Steven Rostedt wrote:
> > On Mon, 11 May 2015 17:10:59 +0200
> > Nicholas Mc Guire <[email protected]> wrote:
> >
> > > rcu_cpu_has_callbacks() is declared int but is actually returning bool and
> > > and as the function description states " * Return true if the specified
> > > CPU has any callback....", this probably should be a bool. All (3)
> > > call-sites currently treat it as bool so the declaration.
> > >
> > >
> > > Signed-off-by: Nicholas Mc Guire <[email protected]>
> > > ---
> > >
> > > V2: fixed up commit message and tool infos as requested by
> > > Josh Triplett <[email protected]>
> > >
> > > Type-checking coccinelle spatches are being used to locate type
> > > mismatches between function signatures and return values.
> > > ./kernel/rcu/tree.c:3538 WARNING: return of wrong type
> > > int != bool,
> > >
> > > Patch was compile tested with x86_64_defconfig (implies CONFIG_TREE_RCU=y)
> > >
> > > Patch is against 4.1-rc3 (localversion-next is -next-20150511)
> >
> > I think what Josh was saying is that all the above except for the "V2"
> > should be above the signature. Everything between the "---" and the
> > patch gets tossed out when committed into git.
> >
> > Giving credit to coccinelle and even what branch and config was used
> > for testing is something we want in the git change log history.
>
> Yes, exactly.
>
ok - sorry for being so complicated.
had been putting config info below in all patches - and in git log I do
not see that information being included - anyway will move it up and
resend in a momemt.
thx!
hofrat
On Mon, 11 May 2015 17:45:10 +0200
Nicholas Mc Guire <[email protected]> wrote:
- sorry for being so complicated.
Nah, we are the ones being complicated.
> had been putting config info below in all patches - and in git log I do
> not see that information being included - anyway will move it up and
> resend in a momemt.
Knowing what config option (or default config build) causes the issues
is helpful. As for what the patch is against, sometimes its best to say
what commit the patch fixes. That even has a tag for it.
-- Steve
On Mon, 11 May 2015, Steven Rostedt wrote:
> On Mon, 11 May 2015 17:45:10 +0200
> Nicholas Mc Guire <[email protected]> wrote:
>
> - sorry for being so complicated.
>
> Nah, we are the ones being complicated.
>
> > had been putting config info below in all patches - and in git log I do
> > not see that information being included - anyway will move it up and
> > resend in a momemt.
>
> Knowing what config option (or default config build) causes the issues
> is helpful. As for what the patch is against, sometimes its best to say
> what commit the patch fixes. That even has a tag for it.
>
gave it one more shot - let me know if that fits - about time I get these
basics right...
thx!
hofrat