Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7788868rdb; Thu, 4 Jan 2024 07:46:58 -0800 (PST) X-Google-Smtp-Source: AGHT+IHOHBPjtc7DT5kN98bnCDdPYjC9EhTNu9IxhemDI2okNW3e6cGYd9LjdSsJj0qA/E93zeYs X-Received: by 2002:a05:6214:f24:b0:680:c837:5817 with SMTP id iw4-20020a0562140f2400b00680c8375817mr895024qvb.19.1704383218172; Thu, 04 Jan 2024 07:46:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704383218; cv=none; d=google.com; s=arc-20160816; b=WHIRojNPLSqmJAmHojKq76AsaZaBJ1LIDQWmtYmOhb920KKnr6nYJV0BtVLaO0ZmT8 xxqY4eGrkM1Q8W13OtEuPHcgi8GsNKpaytzm1uUOdSv0HygI39CMpbLbbigIxwfzvCaV ph8J2spGjHl9Qg1yULSWidOGra5D2vDTIJoh157agSyd+S2ib+0UitC+w4/k/27ll2Q6 ARHNDtplh2Ff+lx9YUvR8STu+5zV8SDmQgKPRv2i85DF4osFcsny+yxq8eOdsd9ZWn3H jLgVXZLR0fWKSKBPkLhOk5osUz96Fa7hIzw9TOvhQ012r5T4yPzTyFL6Qw8EWhetyRdq ws7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=OI8uEb4hGBF4iAYtSjHl3ski8nbBY+2RclBEuC59+Ig=; fh=nc+pSvCwUMv/sZxJEZvT9IKTfRNn1Iv6+CG1dr0PMkE=; b=hPhdZxXbHyMb1nZTnqxOrduw6ysh7ADRPO9s1DZLFif4LabBEzbtz17MMUbha28PKK 2LGjckEXeYAS8x3nmkgolG5yQBhjQ7UjxSJ4h9e0RMytiouhVOlZd+pWCNqgA4rS6vWX g29z5V1CRWqh8utOSppwFkGpGhOgMymGtXDkuawNnjijQVsJyXZmINNAf5SuUZQCYUpM 7hxgnz65Dhs3zW0ir0HqoNVh8FxZC8gOvjRMhO9uuxFLcVIdk4rYK8lffuV+yeE5OiJO aOT1eYMb/zJKRDLF7IW+x5IRR7yfF5CROdJoW7IL09PRRO1NDW8r4jH926A1NUMsxnGr dGdw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-16878-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16878-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id t16-20020a0ce2d0000000b0067efac3f6f5si31660459qvl.67.2024.01.04.07.46.58 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jan 2024 07:46:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-16878-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-16878-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16878-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id E79551C21D90 for ; Thu, 4 Jan 2024 15:46:57 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1D837249FD; Thu, 4 Jan 2024 15:46:34 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 42739249EC for ; Thu, 4 Jan 2024 15:46:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 19763C15; Thu, 4 Jan 2024 07:47:15 -0800 (PST) Received: from [10.57.75.15] (unknown [10.57.75.15]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B8B753F64C; Thu, 4 Jan 2024 07:46:26 -0800 (PST) Message-ID: <04b625e0-58c7-4814-952e-1fb1e1e8ff9c@arm.com> Date: Thu, 4 Jan 2024 16:46:24 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] sched/topology: Annotate RCU pointers properly Content-Language: en-US To: Valentin Schneider , linux-kernel@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira References: <20240103125648.194516-1-pierre.gondois@arm.com> <20240103125648.194516-2-pierre.gondois@arm.com> From: Pierre Gondois In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > > 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 >