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] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 30 Jan 2020 12:45:26 +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 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>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ