From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F5133F0AA9 for ; Wed, 12 Aug 2026 12:04:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786536271; cv=none; b=MKYLqHdpQA3HyTqsBQBjjF7+gzd99EOFq84WsiEh6LpU2Vgs0I8PzHydBCh07o/f1hfp2O5Axi1TZLX0N0NV2wp4FEwQF06ki4RdmpGFotaKp70lEzNn+HCnYjTOh1Ig4s4VTIRxbOfaXCwUsFUwMkviwMuZft9oCgD6TOiLjag= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786536271; c=relaxed/simple; bh=VNl7bbqTFsGy4FFSNk7tIGKAic5oRo/UNOA7SsNhV6w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=R2WeYISNA6p5Wls0jcDngLdnSYKZ/7AgFSXvkLj4TwLylgsK9EJQ6iJo4ZtgAg3DFeA0IY9OuNp0EWnGMo63IFYrXucu62ol6ocT6VpwMfVHBYiyhcdug7u4EBzQbLO+89BJe2s3eV6Tv8v6qyjPp6gzSp6s4YvFv+JdWnBiJjw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=riscstar.com; spf=pass smtp.mailfrom=riscstar.com; dkim=pass (2048-bit key) header.d=riscstar-com.20251104.gappssmtp.com header.i=@riscstar-com.20251104.gappssmtp.com header.b=AK3Mq7Iw; arc=none smtp.client-ip=209.85.222.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=riscstar.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=riscstar.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=riscstar-com.20251104.gappssmtp.com header.i=@riscstar-com.20251104.gappssmtp.com header.b="AK3Mq7Iw" Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-92e5b048375so32306385a.1 for ; Wed, 12 Aug 2026 05:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=riscstar-com.20251104.gappssmtp.com; s=20251104; t=1786536269; x=1787141069; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=T89ODwELGj68fCw+syQii0lYv7lOJLffrGr4iQY0IS8=; b=AK3Mq7IwD1vHE/rzbPMx9OqvLXjMuW66q9/+OFEnYgH7lJdpKnyflS46EKAAcPN81o mnOxoCkNRXlW4wliVJqFrarc0rPJ2G9mRtRm25MdqsBNVeulBygvq4yLa2cQOQpmqPFK aEE+gzPj6GhGBlsAU7tCjZqBbV3MnwpA/BoYGlwFXNCkZz1YAersjrm3L+jXol5ip7qp p13Bh66QqEEET8gOoglk8Brt/r8aZuiIArh/Vm1KLzbyrG5rLTo56tZKJ+/FrkmAKUyT 2renT9wIlnX3cUAf92XTAOSImDLW+gtcbP+0AbMwZ2zhaaCTlTJ2To0C5zrWu3M1Pp1t PiNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786536269; x=1787141069; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=T89ODwELGj68fCw+syQii0lYv7lOJLffrGr4iQY0IS8=; b=GoItDqzORuFjEG2oQkBDznjy/BBjR+r5uZPx/qoz/Ke4EZHMFoM5grg1BuPqhgZWQd I8s7c3tBrTOLMs7VfrBEUyubE3sqEISSgmbFw8du+HD0RXG0v5b5BfQVS1bQYQsu5iq8 2Jj4aZpNFqXGXMH6++kOM+zZCBmqAAx2pzxtAbsA+J3B3/A8cd4VQrQRlqZOz3l55hua 0+UjNBqlYK2xKDfnWEpBcNe4pvLIMt6nug1A8J2kPoGdoh7iGFul3cfuw0DokrEPow7U p/DY5c1+o4+D3SnusG1ekPbqo5LqzZ0GX7kZNVqrsnaafmMYhf/H6/LhZP/E+/VjcTfB MZIQ== X-Forwarded-Encrypted: i=1; AHgh+Ro3T0lZpf/Edl/QzNb+De0qIoqTTi8pfbcOWoWus9wfPmTo9/lg/q/CAJKYgpGnDSafrWUPEze1s6bpRuU=@vger.kernel.org X-Gm-Message-State: AOJu0YyEpwQ3s+BpKfDBz01lLLr/t735xOgmQ1Y/r2LaIZKNALO1X9WR wpuwT9HHE+wOQpwK68Hq+BCqQGo4GOcQpnojRvZEMgzP/beuBE7rVcLHj+QTGtcSMjk= X-Gm-Gg: AR+sD10dRyi5Wu76KekiVfIXqbPuEW5aa9MKM0PZSEOzsbH+Xa3CXe05dKULUogopI3 3Ft6glTOIdu9iGeRpD6gs0AwT6mGnJlokecZ6wnujm63/jFE8TjIOp74PK3t3DgTLIsa6kXRgc8 GYwv0kHXH+38/OXYQaoBefchp+XvUAIfmW/gZVCiygFLzcmQsF9xB5oe5K6MQovDOuHaOqAxa4U 2AQmTpkGgdInPKX8aD+0sgWVnfWO6+XSWXRVpgXJJonUzZznNNfRbL8jevavOUvms4iiQzhL7ZO T7eE8n1Phkpm0ouvcAdjlueljxuv8lQVwMFct26YcC+E8IBJVPsvRh/tg8OHVoww/HrWRtLYpsi iPMCX9BVZtVG9wmPtM33M6ozwsSdjMzqf9Unm4fpDRldjqBKqlD0RkrW3HOLhl/DvdXkyddooYG ERvBt/HZK7HMEqmSANGwnzjsLLePLTf8gjxt4cWQbd88hNxMXhQJgopEQg9JLT X-Received: by 2002:a05:620a:439d:b0:934:9011:596c with SMTP id af79cd13be357-936b3d3e393mr370285985a.24.1786536268917; Wed, 12 Aug 2026 05:04:28 -0700 (PDT) Received: from [172.22.22.28] ([73.62.185.64]) by smtp.gmail.com with ESMTPSA id af79cd13be357-936b5dd3f5fsm114038185a.8.2026.08.12.05.04.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Aug 2026 05:04:28 -0700 (PDT) Message-ID: <75dfd597-4260-444e-b6fa-f8bf2ff9e78b@riscstar.com> Date: Wed, 12 Aug 2026 07:04:26 -0500 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] kernel/sys.c: use RCU when accessing task_struct->real_parent To: Oleg Nesterov Cc: akpm@linux-foundation.org, david@kernel.org, pjw@kernel.org, brauner@kernel.org, ljs@kernel.org, demiobenour@gmail.com, tglx@kernel.org, debug@rivosinc.com, thomas.weissschuh@linutronix.de, linux-kernel@vger.kernel.org References: <20260811190501.1486442-1-elder@riscstar.com> Content-Language: en-US From: Alex Elder In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/12/26 2:55 AM, Oleg Nesterov wrote: > Just in case, I am travelling without my work laptop until Aug 19, > can't read the code and I rarely read emails... > > On 08/11, Alex Elder wrote: >> >> In the setpgid() syscall definition, a check is made to determine >> whether the target process is in the same thread group as the >> current process. The check accesses the target process's real_parent >> pointer directly, however that field is supposed to be accessed via >> RCU. Use rcu_dereference() to avoid this C=1 build warning: >> >> kernel/sys.c:1144:32: warning: incorrect type in argument 1 (different address spaces) > > This is the sparse warning... Do we really care? We have a lot > more users of ->real_parent without rcu_dereference(). > > Note also that the "rcu" annotation of ->real_parent is misleading. > If the task exits, task->real_parent points to nowhere. Same for > ->group_leader. Right, there are some cases where there is other protection as well (like the one you point out below). > This reminds me... months ago I was going to introduce the helper > to access ->group_leader and move it to signal_struct. Then I was > going to do the same with ->real_parent. I sent some preparations, > but then I was distracted. I'll try to return to this after PTO. Yes, this is a better solution overall. I sent this patch to address one warning I kept seeing in my builds, but Andrew pointed out there are lots of others that would also warn. >> SYSCALL_DEFINE2(setpgid, pid_t, pid, pid_t, pgid) >> { >> struct task_struct *p; >> + struct task_struct *real_parent; >> struct task_struct *group_leader = current->group_leader; >> struct pid *pids[PIDTYPE_MAX] = { 0 }; >> struct pid *pgrp; >> @@ -1141,7 +1142,8 @@ SYSCALL_DEFINE2(setpgid, pid_t, pid, pid_t, pgid) >> if (!thread_group_leader(p)) >> goto out; >> >> - if (same_thread_group(p->real_parent, group_leader)) { >> + real_parent = rcu_dereference(p->real_parent); >> + if (same_thread_group(real_parent, group_leader)) { >> err = -EPERM; >> if (task_session(p) != task_session(group_leader)) >> goto out; > > IIRC, this code runs under tasklist_lock (at least it should ;) > ->real_parent is stable. > > I'd prefer to leave this code as is (see above), but even if we > really want to shut up sparse we don't need rcu_dereference() > anyway, we are not going to dereference this pointer. OK that's perfectly fine with me. I retract this patch, and will look forward to you introducing helpers to address this in a more general way. Thanks a lot. -Alex > We have other helpers to read the "rcu" pointers, but I can't > recall the names... > > Oleg. >