[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200130152043.kgcf5s6h6qaalpbl@wittgenstein>
Date: Thu, 30 Jan 2020 16:20:43 +0100
From: Christian Brauner <christian.brauner@...ntu.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: madhuparnabhowmik10@...il.com, peterz@...radead.org,
mingo@...nel.org, paulmck@...nel.org, linux-kernel@...r.kernel.org,
joel@...lfernandes.org,
linux-kernel-mentees@...ts.linuxfoundation.org, rcu@...r.kernel.org
Subject: Re: [PATCH] exit.c: Fix Sparse errors and warnings
On Thu, Jan 30, 2020 at 12:45:26PM +0100, Christian Brauner wrote:
> On January 30, 2020 12:33:41 PM GMT+01:00, Oleg Nesterov <oleg@...hat.com> wrote:
> >On 01/30, Christian Brauner wrote:
> >>
> >> On Thu, Jan 30, 2020 at 11:50:28AM +0530,
> >madhuparnabhowmik10@...il.com wrote:
> >> > From: Madhuparna Bhowmik <madhuparnabhowmik10@...il.com>
> >> >
> >> > This patch fixes the following sparse error:
> >> > kernel/exit.c:627:25: error: incompatible types in comparison
> >expression
> >> >
> >> > And the following warning:
> >> > kernel/exit.c:626:40: warning: incorrect type in assignment
> >> >
> >> > Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@...il.com>
> >>
> >> I think the previous version was already fine but hopefully
> >> RCU_INIT_POINTER() really saves some overhead. In any case:
> >
> >It is not about overhead, RCU_INIT_POINTER() documents the fact that we
> >didn't make any changes to the new parent, we only need to change the
> >pointer.
>
> Right, I wasn't complaining. RCU_INIT_POINTER() claims that it has less overhead than rcu_assign_pointer().
> So that is an additional argument for it.
>
> >
> >And btw, I don't really understand the __rcu annotations. Say,
> >according
> >to sparse this code is wrong:
> >
> > int __rcu *P;
> >
> > void func(int *p)
> > {
> > P = p;
> > }
> >
> >OK, although quite possibly it is fine.
> >
> >However, this code
> >
> > int __rcu *P;
> >
> > void func(int __rcu *p)
> > {
> > *p = 10;
> > P = p;
> > }
> >
> >is almost certainly wrong but sparse is happy, asn is the same.
>
> That's more an argument to fix sparse I guess?
> The annotations themselves are rather useful I think.
> They at least help me when reading the code.
> It's not that rcu lifetimes are trivial and anything that helps remind me that an object wants rcu semantics I'm happy to take it. :)
>
> >
> >
> >> Acked-by: Christian Brauner <christian.brauner@...ntu.com>
> >
> >Acked-by: Oleg Nesterov <oleg@...hat.com>
Thanks, applied for post -rc1.
Christian
Powered by blists - more mailing lists