From: Colin Ian King <[email protected]>
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 <[email protected]>
---
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
On Mon, 4 Dec 2017, Colin King wrote:
> From: Colin Ian King <[email protected]>
>
> 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 <[email protected]>
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 <[email protected]>
--
James Morris
<[email protected]>
James Morris <[email protected]> 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
On Wed, 6 Dec 2017, David Howells wrote:
> James Morris <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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
<[email protected]>