diff mbox series

contigmem: cleanup properly when load fails

Message ID 20200309100025.9022-1-james.r.harris@intel.com (mailing list archive)
State Accepted, archived
Delegated to: David Marchand
Headers
Series contigmem: cleanup properly when load fails |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/iol-testing success Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/Intel-compilation success Compilation OK

Commit Message

Harris, James R March 9, 2020, 10 a.m. UTC 
  If contigmem is not able to allocate all of the
requested buffers, it frees whatever buffers were
able to be allocated up until that point.

But the pointers are not set to NULL in that case.
After the load fails, the FreeBSD kernel will
immediately call the contigmem unload handler, which
tries to free the buffers again since the pointers
were not set to NULL.

It's not clear that we should just rely on the unload
handler getting called after load failure. So let's
keep the existing cleanup code in the load handler,
but explicitly set the pointers to NULL after freeing
them.

Signed-off-by: Jim Harris <james.r.harris@intel.com>
---
 kernel/freebsd/contigmem/contigmem.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

Bruce Richardson March 10, 2020, 9:31 a.m. UTC | #1 
On Mon, Mar 09, 2020 at 03:00:25AM -0700, Jim Harris wrote:
> If contigmem is not able to allocate all of the
> requested buffers, it frees whatever buffers were
> able to be allocated up until that point.
> 
> But the pointers are not set to NULL in that case.
> After the load fails, the FreeBSD kernel will
> immediately call the contigmem unload handler, which
> tries to free the buffers again since the pointers
> were not set to NULL.
> 
> It's not clear that we should just rely on the unload
> handler getting called after load failure. So let's
> keep the existing cleanup code in the load handler,
> but explicitly set the pointers to NULL after freeing
> them.
> 
> Signed-off-by: Jim Harris <james.r.harris@intel.com>
> ---
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
David Marchand March 19, 2020, 12:54 p.m. UTC | #2 
On Tue, Mar 10, 2020 at 10:32 AM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Mon, Mar 09, 2020 at 03:00:25AM -0700, Jim Harris wrote:
> > If contigmem is not able to allocate all of the
> > requested buffers, it frees whatever buffers were
> > able to be allocated up until that point.
> >
> > But the pointers are not set to NULL in that case.
> > After the load fails, the FreeBSD kernel will
> > immediately call the contigmem unload handler, which
> > tries to free the buffers again since the pointers
> > were not set to NULL.
> >
> > It's not clear that we should just rely on the unload
> > handler getting called after load failure. So let's
> > keep the existing cleanup code in the load handler,
> > but explicitly set the pointers to NULL after freeing
> > them.

Can you check this Fixes is correct?

Fixes: 5f51eca22489 ("contigmem: free allocated memory on error")
Cc: stable@dpdk.org
Harris, James R March 19, 2020, 1:52 p.m. UTC | #3 
On 3/19/20, 5:54 AM, "David Marchand" <david.marchand@redhat.com> wrote:

    On Tue, Mar 10, 2020 at 10:32 AM Bruce Richardson
    <bruce.richardson@intel.com> wrote:
    >
    > On Mon, Mar 09, 2020 at 03:00:25AM -0700, Jim Harris wrote:
    > > If contigmem is not able to allocate all of the
    > > requested buffers, it frees whatever buffers were
    > > able to be allocated up until that point.
    > >
    > > But the pointers are not set to NULL in that case.
    > > After the load fails, the FreeBSD kernel will
    > > immediately call the contigmem unload handler, which
    > > tries to free the buffers again since the pointers
    > > were not set to NULL.
    > >
    > > It's not clear that we should just rely on the unload
    > > handler getting called after load failure. So let's
    > > keep the existing cleanup code in the load handler,
    > > but explicitly set the pointers to NULL after freeing
    > > them.
    
    Can you check this Fixes is correct?
    
    Fixes: 5f51eca22489 ("contigmem: free allocated memory on error")
    Cc: stable@dpdk.org
    
Yes - that's correct.  Thanks!

-Jim
David Marchand March 19, 2020, 2:41 p.m. UTC | #4 
On Tue, Mar 10, 2020 at 10:32 AM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Mon, Mar 09, 2020 at 03:00:25AM -0700, Jim Harris wrote:
> > If contigmem is not able to allocate all of the
> > requested buffers, it frees whatever buffers were
> > able to be allocated up until that point.
> >
> > But the pointers are not set to NULL in that case.
> > After the load fails, the FreeBSD kernel will
> > immediately call the contigmem unload handler, which
> > tries to free the buffers again since the pointers
> > were not set to NULL.
> >
> > It's not clear that we should just rely on the unload
> > handler getting called after load failure. So let's
> > keep the existing cleanup code in the load handler,
> > but explicitly set the pointers to NULL after freeing
> > them.

Fixes: 5f51eca22489 ("contigmem: free allocated memory on error")
Cc: stable@dpdk.org

> >
> > Signed-off-by: Jim Harris <james.r.harris@intel.com>
> > ---
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
>

Applied, thanks.
diff mbox series

Patch

diff --git a/kernel/freebsd/contigmem/contigmem.c b/kernel/freebsd/contigmem/contigmem.c
index 64e0a7fec..abb76f241 100644
--- a/kernel/freebsd/contigmem/contigmem.c
+++ b/kernel/freebsd/contigmem/contigmem.c
@@ -165,9 +165,11 @@  contigmem_load()
 
 error:
 	for (i = 0; i < contigmem_num_buffers; i++) {
-		if (contigmem_buffers[i].addr != NULL)
+		if (contigmem_buffers[i].addr != NULL) {
 			contigfree(contigmem_buffers[i].addr,
 				contigmem_buffer_size, M_CONTIGMEM);
+			contigmem_buffers[i].addr = NULL;
+		}
 		if (mtx_initialized(&contigmem_buffers[i].mtx))
 			mtx_destroy(&contigmem_buffers[i].mtx);
 	}