From: Greg Kurz <hidden> Date: 2018-12-10 15:32:24
The only users of free_spa() are alloc_link() and free_link(), and
in both cases:
- link->spa != NULL
- free_spa(link) is immediatly followed by kfree(link)
The check isn't needed, and it doesn't bring much to clear the link->spa
pointer. Drop both.
Signed-off-by: Greg Kurz <redacted>
---
drivers/misc/ocxl/link.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
The only users of free_spa() are alloc_link() and free_link(), and
in both cases:
- link->spa != NULL
- free_spa(link) is immediatly followed by kfree(link)
The check isn't needed, and it doesn't bring much to clear the link->spa
pointer. Drop both.
Signed-off-by: Greg Kurz <redacted>
---
OK, that looks safe enough
Acked-by: Frederic Barrat <redacted>
From: Andrew Donnellan <hidden> Date: 2018-12-11 01:05:57
On 11/12/18 2:15 am, Greg Kurz wrote:
The only users of free_spa() are alloc_link() and free_link(), and
in both cases:
- link->spa != NULL
- free_spa(link) is immediatly followed by kfree(link)
The check isn't needed, and it doesn't bring much to clear the link->spa
pointer. Drop both.
Signed-off-by: Greg Kurz <redacted>
I like defensive programming but for this case I don't really care too
much either way
Acked-by: Andrew Donnellan <redacted>
From: Greg Kurz <hidden> Date: 2018-12-11 09:07:51
On Tue, 11 Dec 2018 12:05:49 +1100
Andrew Donnellan [off-list ref] wrote:
On 11/12/18 2:15 am, Greg Kurz wrote:
quoted
The only users of free_spa() are alloc_link() and free_link(), and
in both cases:
- link->spa != NULL
- free_spa(link) is immediatly followed by kfree(link)
The check isn't needed, and it doesn't bring much to clear the link->spa
pointer. Drop both.
Signed-off-by: Greg Kurz <redacted>
I like defensive programming but for this case I don't really care too
much either way
I now realize that I should have mentioned the real motivation for this
change. I'm working on refactoring the code so that we can use ocxl in a
KVM guest. The concept of link can be shared by both powernv and pseries
variants but the SPA is definitely a powernv only thingy. The benefit
of this patch is hence to kick 'struct link' out of free_spa() so that
it can be utimately moved to powernv specific code.
The initial version of this change was just moving the link->spa check
and link->spa = NULL to the callers, where it was quite obvious they're
not needed... Should I re-post this as two patches for clarity ?
From: Andrew Donnellan <hidden> Date: 2018-12-11 09:13:29
On 11/12/18 7:57 pm, Greg Kurz wrote:
I now realize that I should have mentioned the real motivation for this
change. I'm working on refactoring the code so that we can use ocxl in a
KVM guest. The concept of link can be shared by both powernv and pseries
variants but the SPA is definitely a powernv only thingy. The benefit
of this patch is hence to kick 'struct link' out of free_spa() so that
it can be utimately moved to powernv specific code.
The initial version of this change was just moving the link->spa check
and link->spa = NULL to the callers, where it was quite obvious they're
not needed... Should I re-post this as two patches for clarity ?
Ah, that makes much more sense.
If that's the case, then why not go all the way and change the function
signature while you're at it?
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
From: Greg Kurz <hidden> Date: 2018-12-11 10:12:53
On Tue, 11 Dec 2018 20:13:21 +1100
Andrew Donnellan [off-list ref] wrote:
On 11/12/18 7:57 pm, Greg Kurz wrote:
quoted
I now realize that I should have mentioned the real motivation for this
change. I'm working on refactoring the code so that we can use ocxl in a
KVM guest. The concept of link can be shared by both powernv and pseries
variants but the SPA is definitely a powernv only thingy. The benefit
of this patch is hence to kick 'struct link' out of free_spa() so that
it can be utimately moved to powernv specific code.
The initial version of this change was just moving the link->spa check
and link->spa = NULL to the callers, where it was quite obvious they're
not needed... Should I re-post this as two patches for clarity ?
Ah, that makes much more sense.
If that's the case, then why not go all the way and change the function
signature while you're at it?