[lwip-devel] [bug #47172] mem.c mem_malloc implementation does not properly account for MEM_ALIGNMENT

[David Fernandez]

URL:
  <http://savannah.nongnu.org/bugs/?47172>

                 Summary: mem.c mem_malloc implementation does not properly
account for MEM_ALIGNMENT
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: david0fc
            Submitted on: Tue 16 Feb 2016 20:51:06 GMT
                Category: Platform ports
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: git head

    _______________________________________________________

Details:

The current malloc metadata is defined as:

/**
 * The heap is made up as a list of structs of this type.
 * This does not have to be aligned since for getting its size,
 * we only use the macro SIZEOF_STRUCT_MEM, which automatically aligns.
 */
struct mem {
  /** index (-> ram[next]) of the next struct */
  mem_size_t next;
  /** index (-> ram[prev]) of the previous struct */
  mem_size_t prev;
  /** 1: this area is used; 0: this area is unused */
  u8_t used;
};

Which claims not to need alignment due to the pointers to it being aligned.

The problem is that some platforms require to write the full aligned size,
before reads, or they will trigger ECC/Parity errors.

This is specially relied on for heaps (which won't go in bss), so that proper
memory usage is enforced.

A simple fix is to memset with 0 the block first, as just initializing the
fields, as it is currently done, is not enough (the reason is that some memory
systems use byte-enables for writes, but not for reads).

So this bug is to request that a memset is done for the metadata aligned size.




    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?47172>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/