Hi Shreyansh,
On Fri, 31 Mar 2017 11:11:19 +0530, Shreyansh Jain <shreyansh.j...@nxp.com>
wrote:
> On Friday 31 March 2017 11:05 AM, Shreyansh Jain wrote:
> > Fixes: 449c49b93a6b ("mempool: support handler operations")
> >
> > In case the stack or ring mempool handler are compiled as shared
> > library and not linked in with test binary, segfault is reported.
> > This is because return value of rte_mempool_set_ops_byname is not
> > being checked in rte_mempool_ops_alloc.
> >
> > This patch handles error returned from rte_mempool_set_ops_byname
> > when a mempool is not found.
> >
> > Signed-off-by: Shreyansh Jain <shreyansh.j...@nxp.com>
> > ---
>
> $ devtools/check-git-log.sh <this patch>
> Is it candidate for Cc: sta...@dpdk.org backport?
> mempool: fix segfault when shared mempool handler not linked
>
> I am not sure this needs to be in stable. Previous versions never had
> an external mempool handler and ring/stack are statically linked in
> always.
> Though, if a new handler is added (out of tree) over 16.11, and somehow
> and application requests for it without linking the library, this
> segfault would occur.
>
> Any suggestions?
>
> And just to add to this patch, this segfault is in 'test' binary. It may
> not necessarily be the case for other application if they are
> handling the error well.
>
I think it's not needed to backport in stable. As you said, the
crash cannot occur because ring handler is always registered (it's
part of the same mempool lib).
Thanks,
Olivier
