From: Thomas Monjalon <thomas@monjalon.net>
To: Anatoly Burakov <anatoly.burakov@intel.com>
Cc: dev@dpdk.org, stable@dpdk.org
Subject: Re: [PATCH] eal: fix end for bounded malloc elements
Date: Fri, 12 Jan 2018 15:54:33 +0100 [thread overview]
Message-ID: <17429603.yn0ZjX41h2@xps> (raw)
In-Reply-To: <be459294da93f5013e8a7be203a0253787224b2d.1513865614.git.anatoly.burakov@intel.com>
21/12/2017 17:54, Anatoly Burakov:
> In cases when alignment is bigger than boundary, we may incorrectly
> calculate end of a bounded malloc element.
>
> Consider this: suppose we are allocating a bounded malloc element
> that should be of 128 bytes in size, bounded to 128 bytes and
> aligned on a 256-byte boundary. Suppose our malloc element ends
> at 0x140 - that is, 256 plus one cacheline.
>
> So, right at the start, we are aligning our new_data_start to
> include the required element size, and to be aligned on a specified
> boundary - so new_data_start becomes 0. This fails the following
> bounds check, because our element cannot go above 128 bytes from
> the start, and we are at 320. So, we enter the bounds handling
> branch.
>
> While we're in there, we are aligning end_pt to our boundedness
> requirement of 128 byte, and end up with 0x100 (since 256 is
> 128-byte aligned). We recalculate new_data_size and it stays at
> 0, however our end is at 0x100, which is beyond the 128 byte
> boundary, and we report inability to reserve a bounded element
> when we could have.
>
> This patch adds an end_pt recalculation after new_data_start
> adjustment - we already know that size <= bound, so we can do it
> safely - and we then correctly report that we can, in fact, try
> using this element for bounded malloc allocation.
>
> Fixes: fafcc11985a2 ("mem: rework memzone to be allocated by malloc")
> Cc: sergio.gonzalez.monroy@intel.com
> Cc: stable@dpdk.org
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
It looks to be a headache, but as the maintainer of DPDK memory,
I trust you :)
Applied, thanks
prev parent reply other threads:[~2018-01-12 14:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-21 16:54 [PATCH] eal: fix end for bounded malloc elements Anatoly Burakov
2018-01-12 14:54 ` Thomas Monjalon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17429603.yn0ZjX41h2@xps \
--to=thomas@monjalon.net \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=stable@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.