public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Joe Seymour <joe.s@somniumtech.com>
To: Joey Ye <joey.ye.cc@gmail.com>,
	"newlib@sourceware.org" <newlib@sourceware.org>,
	Joey Ye <joey.ye@arm.com>, Bin Cheng <bin.cheng@arm.com>
Subject: Re: [PATCH 2/2] Fix padding initialization in nano_malloc?
Date: Wed, 11 Jan 2017 14:58:00 -0000	[thread overview]
Message-ID: <86a82ca0-e380-4201-1041-f15d2f7a832a@somniumtech.com> (raw)
In-Reply-To: <CAL0py24HxO8u5f7DC0vfAPj+KXKfmxmfFAEBr3gBCu8APvaGKw@mail.gmail.com>

Hi Joey,

On 10/01/2017 03:45, Joey Ye wrote:
> Thanks for reading the code and starting this discussion. But IMHO you
> misunderstood the data structure thus this patch is not valid.

Thanks for the review! I agree and withdraw that patch.

I was thinking of the padding as being like a variable-length field in the
structure, which led me to assume that the offset was being read/written from
the beginning of the padding, instead of the end.

To try and stop anyone else making the same mistake I've prepared the following
patch, which adds some more comments to nano-mallocr.c. Note that I haven't
verified that the existing code ensures that the size of padding is at least
CHUNK_OFFSET.

What do you think?

Thanks,

Joe Seymour

---
 newlib/libc/stdlib/nano-mallocr.c |   23 ++++++++++++++++++++---
 1 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/newlib/libc/stdlib/nano-mallocr.c b/newlib/libc/stdlib/nano-mallocr.c
index 457eb88..4497eb6 100644
--- a/newlib/libc/stdlib/nano-mallocr.c
+++ b/newlib/libc/stdlib/nano-mallocr.c
@@ -128,7 +128,7 @@ typedef struct malloc_chunk
      *          ------------------
      *          | Padding for    |
      *          | alignment      |
-     *          | holding neg    |
+     *          | ending with neg|
      *          | offset to size |
      *          ------------------
      * mem_ptr->| point to next  |
@@ -187,9 +187,23 @@ extern void * nano_pvalloc(RARG size_t s);
 
 static inline chunk * get_chunk_from_ptr(void * ptr)
 {
+    /* Assume that there is no explicit padding in the
+       chunk, and that the chunk starts at ptr - CHUNK_OFFSET.  */
     chunk * c = (chunk *)((char *)ptr - CHUNK_OFFSET);
-    /* Skip the padding area */
-    if (c->size < 0) c = (chunk *)((char *)c + c->size);
+
+    if (c->size < 0) {
+      /* c->size being negative indicates that there is explicit padding in
+         the chunk; c->size is actually the last CHUNK_OFFSET bytes in that
+         padding.
+
+         To find the true start of the chunk we need to subtract the size of
+         any remaining padding, and then CHUNK_OFFSET from c.  This is
+         equivalent to subtracting the total size of the padding from c,
+         because the size of any remaining padding is the total size of the
+         padding minus CHUNK_OFFSET.  The end of the padding should have been
+         initialized with this negative offset.  */
+      c = (chunk *)((char *)c + c->size);
+    }
     return c;
 }
 
@@ -314,6 +328,9 @@ void * nano_malloc(RARG malloc_size_t s)
 
     if (offset)
     {
+        /* Initialize the end of the padding with a negative offset to the
+           start of the chunk.  The rest of the padding is not initialized.
+           Note that the size of the padding must be at least CHUNK_OFFSET.  */
         *(long *)((char *)r + offset) = -offset;
     }
 
-- 
1.7.1

  reply	other threads:[~2017-01-11 14:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-03 14:56 Joe Seymour
2017-01-09 15:19 ` Corinna Vinschen
2017-01-10  3:46   ` Joey Ye
2017-01-11 14:58     ` Joe Seymour [this message]
2017-01-12  2:24       ` Joey Ye
2017-01-12 11:08         ` Joe Seymour
     [not found]           ` <CAL0py26LuRBbutD+APt2bTT6VVuYARr2SzQn3xpJXVht8tJAZw@mail.gmail.com>
2017-01-13 12:51             ` Joe Seymour
     [not found]               ` <HE1PR0801MB2073A1D97DC6A6C87F425A66E0780@HE1PR0801MB2073.eurprd08.prod.outlook.com>
2017-01-13 14:13                 ` Joe Seymour
2017-01-13 15:02                   ` Corinna Vinschen
2017-01-13 15:37                     ` Joe Seymour

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=86a82ca0-e380-4201-1041-f15d2f7a832a@somniumtech.com \
    --to=joe.s@somniumtech.com \
    --cc=bin.cheng@arm.com \
    --cc=joey.ye.cc@gmail.com \
    --cc=joey.ye@arm.com \
    --cc=newlib@sourceware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).