[PATCH] security: keys: remove redundant assignment to key_ref

[PATCH] security: keys: remove redundant assignment to key_ref

[Colin King]

From: Colin Ian King <colin.king@canonical.com>

Variable key_ref is being assigned a value that is never read;
key_ref is being re-assigned a few statements later.  Hence this
assignment is redundant and can be removed.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
 security/keys/key.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/security/keys/key.c b/security/keys/key.c
index 66049183ad89..d97c9394b5dd 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -833,7 +833,6 @@ key_ref_t key_create_or_update(key_ref_t keyring_ref,
 
 	key_check(keyring);
 
-	key_ref = ERR_PTR(-EPERM);
 	if (!(flags & KEY_ALLOC_BYPASS_RESTRICTION))
 		restrict_link = keyring->restrict_link;
 
-- 
2.14.1

Re: [PATCH] security: keys: remove redundant assignment to key_ref

[James Morris]

On Mon, 4 Dec 2017, Colin King wrote:

> From: Colin Ian King <colin.king@canonical.com>
> 
> Variable key_ref is being assigned a value that is never read;
> key_ref is being re-assigned a few statements later.  Hence this
> assignment is redundant and can be removed.
> 
> Signed-off-by: Colin Ian King <colin.king@canonical.com>

I think a general cleanup in that function to make all of these follow the 
pattern:

	if (something) {
		key_ref = ERR_PTR(-error);
		goto error;
	}

rather than unconditionally setting the error first, would be better, but 
this is a clear enough fix on its own.

Reviewed-by: James Morris <james.l.morris@oracle.com>


-- 
James Morris
<james.l.morris@oracle.com>

Re: [PATCH] security: keys: remove redundant assignment to key_ref

[David Howells]

James Morris <james.l.morris@oracle.com> wrote:

> I think a general cleanup in that function to make all of these follow the 
> pattern:
> 
> 	if (something) {
> 		key_ref = ERR_PTR(-error);
> 		goto error;
> 	}
> 
> rather than unconditionally setting the error first, would be better, but 
> this is a clear enough fix on its own.

There's a preference in Linux to use:

	key_ref = ERR_PTR(-error);
 	if (something)
 		goto error;

instead because it uses less vertical space.  It might originally have been
promulgated by Linus, but I don't remember.  Though you do have a point - your
way makes error handling less subject breakage from code rearrangement.

David

Re: [PATCH] security: keys: remove redundant assignment to key_ref

[Julia Lawall]

On Wed, 6 Dec 2017, David Howells wrote:

> James Morris <james.l.morris@oracle.com> wrote:
>
> > I think a general cleanup in that function to make all of these follow the
> > pattern:
> >
> > 	if (something) {
> > 		key_ref = ERR_PTR(-error);
> > 		goto error;
> > 	}
> >
> > rather than unconditionally setting the error first, would be better, but
> > this is a clear enough fix on its own.
>
> There's a preference in Linux to use:
>
> 	key_ref = ERR_PTR(-error);
>  	if (something)
>  		goto error;
>
> instead because it uses less vertical space.  It might originally have been
> promulgated by Linus, but I don't remember.  Though you do have a point - your
> way makes error handling less subject breakage from code rearrangement.

I have the impression that there are many examples of both approaches.

julia

>
> David
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH] security: keys: remove redundant assignment to key_ref

[James Morris]

On Wed, 6 Dec 2017, Julia Lawall wrote:

> > There's a preference in Linux to use:
> >
> > 	key_ref = ERR_PTR(-error);
> >  	if (something)
> >  		goto error;
> >
> > instead because it uses less vertical space.  It might originally have been
> > promulgated by Linus, but I don't remember.  Though you do have a point - your
> > way makes error handling less subject breakage from code rearrangement.
> 
> I have the impression that there are many examples of both approaches.

I thought this was mainly to set a default error condition once and then 
some call during the function sets it to zero on success.


-- 
James Morris
<james.l.morris@oracle.com>