Received: by 2002:a05:7412:a9a2:b0:e2:908c:2ebd with SMTP id o34csp74588rdh; Wed, 25 Oct 2023 16:52:15 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEckAKwYvvCZxonojeKX+JpBs8GGxuAM5Ir2zKS2P4EjRg91XjA6sNCLCXsuzvQhNxAsDcL X-Received: by 2002:a25:3489:0:b0:d7a:d716:233c with SMTP id b131-20020a253489000000b00d7ad716233cmr15960381yba.41.1698277935610; Wed, 25 Oct 2023 16:52:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698277935; cv=none; d=google.com; s=arc-20160816; b=qb7VTRP9LtCppTS6bI7ZyW9aNu6B9iGL5a33m6kkWNEEZ4Py58yxhzkibsnQNycDNS NAVcvB+HAIgAStvwC/M67NbN/Idm33xaP/TBAambXWDPyh5PIGhUAtXCbqd37lBA04ol 1ba29vpJqqsomSKIgO/QPTUqrjuocLChW7zeO9TAbyT4luMVPTfb27iggii+ym7tx+XY PZ9RCmltLjnfqgCq8hJH5+ClbRJKS6jWDXmpE0pvSiWC4s5pZef4erH2vq+9oyS8eho3 0isQqoX4y4oDLLHTedPLV6/9GWKM307b2lxSBIvVQEeOnP+B7iA8QjJLqsjo70US9Eke cbSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=GYJw6TmkXRk1PH+5n9KijYPoYiQWq2qmDb3rpjEDDqs=; fh=3o4UfZdmTwLWOFZmQh0r3WSnauBEEN/P8hydeK8Pk6A=; b=o0sh9M4nd7P1cDqogsd9sHx6CQEo2+dQVo8LMVOD9mHN0R7Vj4TKmhOjOhcu/zjF4Q t1vUP+3CzOkFhYxVQqF8nViklwKw3hU5Zf0mxE20jtHvfoX8MoVi+OR0r4pdnOP5ydtR 6mqAiMD8YY697A2Se3Qgk+JsWDF3id6xsz+AOw8KbLGJ7QDLd8LV9WvhClMCso4RxeNb /kfowtP060CEuNBR74J1p8hhMVsbLmxq9Lu7z7AYt7UVBoSZLj0OPXpMyCtyVfrLZn03 59cx+qfftPiYUCrlhu97ujFiuRkr4Ko7hFO2ySjdZMQL4bX6v+NpP6Cyl0kL9a40PiPa kvnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=SslKzLdR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id t9-20020a25f609000000b00d81456a151asi12716466ybd.626.2023.10.25.16.52.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Oct 2023 16:52:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=SslKzLdR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id E00BC81E9F40; Wed, 25 Oct 2023 16:52:10 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230281AbjJYXwC (ORCPT + 99 others); Wed, 25 Oct 2023 19:52:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44906 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234958AbjJYXun (ORCPT ); Wed, 25 Oct 2023 19:50:43 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 840121724 for ; Wed, 25 Oct 2023 16:50:03 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC170C433C8; Wed, 25 Oct 2023 23:50:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1698277803; bh=6OD+Y8pC8d8yXq2muD5OMoXQ/nN+x9qvm8b1lOdybRw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=SslKzLdRm4iZqyvE7RbWtt9Aksd3C7S8t9WOVMqHiU01qLnnWfuOI1acjomn6Ofqt VEyftpRTUL5xrZsrV9ynMdQ1Mw14ccax3sXuh9QwSgUxCb9n6TWhiCYepofTpd15yG scVTwOaavC2imdr1NJVbokiFhzuK+aQM2cujCQJs= Date: Wed, 25 Oct 2023 16:50:02 -0700 From: Andrew Morton To: Abhinav Singh Cc: brauner@kernel.org, surenb@google.com, mst@redhat.com, michael.christie@oracle.com, mathieu.desnoyers@efficios.com, mjguzik@gmail.com, npiggin@gmail.com, shakeelb@google.com, peterz@infradead.org, linux-kernel@vger.kernel.org, linux-kernel-mentees@lists.linuxfoundation.org Subject: Re: [PATCH] Fixing warning of directly dereferencing __rcu tagged Message-Id: <20231025165002.64ab92e6d55d204b66e055f4@linux-foundation.org> In-Reply-To: References: <20231025222811.855336-1-singhabhinav9051571833@gmail.com> <20231025153807.8db950f1db82b2c9ecd03758@linux-foundation.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Wed, 25 Oct 2023 16:52:11 -0700 (PDT) On Thu, 26 Oct 2023 04:57:42 +0530 Abhinav Singh wrote: > On 10/26/23 04:08, Andrew Morton wrote: > >> +++ b/kernel/fork.c > >> @@ -2369,7 +2369,9 @@ __latent_entropy struct task_struct *copy_process( > >> > >> retval = -EAGAIN; > >> if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) { > >> - if (p->real_cred->user != INIT_USER && > >> + const struct cred *real_cred = rcu_dereference(p->real_cred); > >> + > >> + if (real_cred && real_cred->user != INIT_USER && > >> !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) > >> goto bad_fork_cleanup_count; > > > > The old code assumes that p->read_cred cannot be NULL and the new code > > does nothing to make it possible that `real_cred' can be NULL? > > > > In other words, I see no reason to add this new check for NULL? > > Thank you for the response! > > I thought it will be better to have check before accessing it, just so > we dont have any segmentation fault in future. That would be adding code which has no effect? > Also I just noticed there are two more places where direct dereferencing > of __rcu pointer is done in this same file. Should I do those changes in > this patch ? I don't see why. rcu_dereference(p) cannot return NULL if `p' is non-NULL?