linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com>
To: Li zeming <zeming@nfschina.com>
Cc: serge@hallyn.com, linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kernel: capability: Remove unnecessary ‘0’ values from ret
Date: Wed, 10 Jan 2024 09:47:46 -0600	[thread overview]
Message-ID: <20240110154746.GA92832@mail.hallyn.com> (raw)
In-Reply-To: <20231228030854.11689-1-zeming@nfschina.com>

On Thu, Dec 28, 2023 at 11:08:54AM +0800, Li zeming wrote:
> The ret variable is assigned when it does not need to be defined, as it
> has already been assigned before use.
> 
> Signed-off-by: Li zeming <zeming@nfschina.com>

This is true, so the patch would fine now.  But it has not always been
the case, and a future patch could add code at the start which makes it
no longer true.  While I'd hope we would easily catch that, I'm just not
sure it's worth it.  In fact I'm curious - does the compiler recognize
this situation and optimize the = 0 away?

> ---
>  kernel/capability.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/capability.c b/kernel/capability.c
> index dac4df77e376e..ed8a983e21da4 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -140,7 +140,7 @@ static inline int cap_get_target_pid(pid_t pid, kernel_cap_t *pEp,
>   */
>  SYSCALL_DEFINE2(capget, cap_user_header_t, header, cap_user_data_t, dataptr)
>  {
> -	int ret = 0;
> +	int ret;
>  	pid_t pid;
>  	unsigned tocopy;
>  	kernel_cap_t pE, pI, pP;
> -- 
> 2.18.2

      reply	other threads:[~2024-01-10 15:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-28  3:08 [PATCH] kernel: capability: Remove unnecessary ‘0’ values from ret Li zeming
2024-01-10 15:47 ` Serge E. Hallyn [this message]

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=20240110154746.GA92832@mail.hallyn.com \
    --to=serge@hallyn.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=zeming@nfschina.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;
as well as URLs for NNTP newsgroup(s).