mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pierre Gondois <pierre.gondois@arm.com>
To: Valentin Schneider <vschneid@redhat.com>, linux-kernel@vger.kernel.org
Cc: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Daniel Bristot de Oliveira <bristot@redhat.com>
Subject: Re: [PATCH 1/2] sched/topology: Annotate RCU pointers properly
Date: Thu, 4 Jan 2024 16:46:24 +0100	[thread overview]
Message-ID: <04b625e0-58c7-4814-952e-1fb1e1e8ff9c@arm.com> (raw)
In-Reply-To: <xhsmh1qaxjuf1.mognet@vschneid-thinkpadt14sgen2i.remote.csb>

Hello Valentin,

On 1/4/24 10:54, Valentin Schneider wrote:
> On 03/01/24 13:56, Pierre Gondois wrote:
>> Cleanup RCU-related spare errors by annotating RCU pointers.
>>
>> sched_domains_numa_distance:
>>    error: incompatible types in comparison expression
>>    (different address spaces):
>>        int [noderef] __rcu *
>>        int *
>>
>> sched_domains_numa_masks:
>>    error: incompatible types in comparison expression
>>    (different address spaces):
>>        struct cpumask **[noderef] __rcu *
>>        struct cpumask ***
>>
>> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> 
> That's from when the NUMA topologies were made dynamic, which should be:
> Fixes: 0fb3978b0aac ("sched/numa: Fix NUMA topology for systems with CPU-less nodes")

Ok yes

>> ---
>>   kernel/sched/topology.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
>> index 10d1391e7416..0342a4f41f09 100644
>> --- a/kernel/sched/topology.c
>> +++ b/kernel/sched/topology.c
>> @@ -1542,8 +1542,8 @@ static int			sched_domains_numa_levels;
>>   static int			sched_domains_curr_level;
>>
>>   int				sched_max_numa_distance;
>> -static int			*sched_domains_numa_distance;
>> -static struct cpumask		***sched_domains_numa_masks;
>> +static int			__rcu *sched_domains_numa_distance;
>> +static struct cpumask		** __rcu *sched_domains_numa_masks;
> 
> I understand that's what sparse is asking for, but that looks odd to me. We
> use it as:
> 
>    rcu_assign_pointer(sched_domains_numa_masks, foo);
> 
> so why isn't it
> 
>    __rcu ***sched_domains_numa_masks;
> 
> ?
> 
> This isn't a pointer to an RCU-protected array of masks, this is an
> RCU-protected double array of masks.

I think:
   static struct cpumask ** __rcu *sched_domains_numa_masks;
should denote an RCU-protected array^3 of 'struct cpumask', when
   static struct cpumask __rcu ***sched_domains_numa_masks;
would denote an array^2 of RCU-protected 'struct cpumask*',
and assignments would look like:
   rcu_assign_pointer(**sched_domains_numa_masks, foo);

Meaning that, when taking as a better example:
   static int __rcu *sched_domains_numa_distance;
Here we would like to avoid having 'access after free' to the array of
integer allocated to sched_domains_numa_distance.

For sched_domains_numa_masks:
   static struct cpumask	** __rcu *sched_domains_numa_masks;
   rcu_assign_pointer(sched_domains_numa_masks, foo);
   bar = rcu_dereference(sched_domains_numa_masks);
once the first array pointed by sched_domains_numa_masks is accessed/assigned,
we know the RCU-framework makes it safe against 'accesses after free' when
accessing the level-2 array of sched_domains_numa_masks, or accessing the mask
(level 3).

Please let me know if the reasoning seems dodgy.

About the kernel test robot:
   kernel/sched/topology.c:1998:19: sparse: sparse: incorrect type in assignment (different address spaces) @@
        expected int *distances @@
        got int [noderef] __rcu *static [addressable] [assigned] [toplevel] sched_domains_numa_distance
   kernel/sched/topology.c:2000:15: sparse: sparse: incorrect type in assignment (different address spaces) @@
        expected struct cpumask ***masks @@
        got struct cpumask **[noderef] __rcu *static [addressable] [assigned] [toplevel] sched_domains_numa_masks @@
I think the warnings can be ignored since the two pointers (distances, masks)
are only dereferenced after a 'synchronize_rcu()'

Regards,
Pierre

>>   #endif
>>
>>   /*
>> --
>> 2.25.1
> 

  reply	other threads:[~2024-01-04 15:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-03 12:56 [PATCH 0/2] Small cleanup around sparse report Pierre Gondois
2024-01-03 12:56 ` [PATCH 1/2] sched/topology: Annotate RCU pointers properly Pierre Gondois
2024-01-04  9:54   ` Valentin Schneider
2024-01-04 15:46     ` Pierre Gondois [this message]
2024-01-04 14:54   ` kernel test robot
2024-01-03 12:56 ` [PATCH 2/2] sched/fair: Use rq in idle_cpu_without() Pierre Gondois
2024-01-04  5:15   ` Shrikanth Hegde
2024-01-04 16:12     ` Pierre Gondois

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=04b625e0-58c7-4814-952e-1fb1e1e8ff9c@arm.com \
    --to=pierre.gondois@arm.com \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®