This is a classic case.
Programmers are lazy when it comes to handling run time errors, and hackers are
eager to exploit such shortsighted approach.
When a network app is passing traffic , there is always a chance that it lacks
the resources to handle the traffic load, and it will inevitable run out of
buffers in some pool. This is why it is important to dedicate separate buffer
pools for different classes of service.
We should guide all implementers and app developers to take an explicit "packet
drop" action to recover from allocation failure.
{ Leo }
> On Sep 2, 2014, at 8:40 AM, "Alexandru Badicioiu"
> <[email protected]> wrote:
>
> Hi,
> I noticed that alloc_pkt_ctx function calls abort() in case of allocation
> failure.
> I think a better approach to handle this error is to return a NULL pointer,
> free the input buffer (packet) and continue with the schedule loop.
>
> static
> pkt_ctx_t *alloc_pkt_ctx(odp_packet_t pkt)
> {
> odp_buffer_t ctx_buf = odp_buffer_alloc(ctx_pool);
> pkt_ctx_t *ctx;
>
> /* There should always be enough contexts */
> if (odp_unlikely(ODP_BUFFER_INVALID == ctx_buf))
> - abort();
> + return NULL;
>
> if ((completionq != dispatchq) && (seqnumq != dispatchq)) {
> ctx = alloc_pkt_ctx(pkt);
> + if (!ctx) {
> + odp_buffer_free(buf);
> + continue;
> + }
> ctx->state = PKT_STATE_INPUT_VERIFY;
>
> Thanks,
> Alex
> _______________________________________________
> lng-odp mailing list
> [email protected]
> http://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp
