talos-skiboot/core/test/run-malloc.c, branch master

lock: Add additional lock auditing code

2017-12-21T04:15:36+00:00

Keep track of lock owner name and replace lock_depth counter with a per-cpu list of locks held by the cpu. This allows us to print the actual locks held in case we hit the (in)famous message about opal_pollers being run with a lock held. It also allows us to warn (and drop them) if locks are still held when returning to the OS or completing a scheduled job. Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Nicholas Piggin [stewart: fix unit tests] Signed-off-by: Stewart Smith

Fix harmless free() after realloc() in test-malloc.c

2015-09-09T05:51:23+00:00

Signed-off-by: Stewart Smith

trivial run-malloc test fixup that was fooling coverity

2015-09-08T03:53:24+00:00

although we assert that p2==p, coverity doesn't pick this up, so we get a false positive of a double free. This is trivial to fix just by modifying our test case. Signed-off-by: Stewart Smith

core: Add asserts for region free-list locking

2015-05-13T04:01:35+00:00

This change adds asserts to the mem_region calls that should have the per-region lock held. To keep the tests working, they need the lock_held_by_me() function. The run-mem_region.c test has a bogus implementation of this, as it doesn't do any locking at the moment. This will be addressed in a later change. Signed-off-by: Jeremy Kerr Signed-off-by: Stewart Smith

core: Move free-list locking to a separate per-region lock

2015-05-13T04:01:35+00:00

Currently, we have a single lock for the entire mem_region system; this protects both the global region list, and the allocations from each region. This means we can't allocate memory while traversing the global region list, as any malloc/realloc/free will try to acquire the mem_region lock again. This change separates the locking into different functions. We keep the mem_region_lock to protect the regions list, and introduce a per-region lock to protect allocations from the regions' free_lists. Then we remove the open-coded invocations of mem_alloc, where we'd avoided malloc() due to the above locking issue. Signed-off-by: Jeremy Kerr Signed-off-by: Stewart Smith

Fix unused result of realloc warning in core/test/run-malloc.c

2014-12-05T00:53:00+00:00

Signed-off-by: Stewart Smith

Test zalloc() failure case.

2014-10-22T06:01:27+00:00

This brings us to near total test coverage of core/malloc.c Signed-off-by: Stewart Smith

Add unit test for realloc failure

2014-10-22T05:57:09+00:00

Increases test coverage of realloc too! Was: Hit Total Coverage Lines: 1936 2574 75.2 % Functions: 177 225 78.7 % Branches: 1243 2360 52.7 % Now: Lines: 1945 2582 75.3 % Functions: 177 225 78.7 % Branches: 1247 2364 52.7 % Signed-off-by: Stewart Smith

in realloc(), memcpy() call would copy past end of allocation

2014-10-17T00:55:16+00:00

or: Fix mem_size() to remove struct alloc_hdr from returned value This bug was caught by switching test/run-malloc.c over to using malloc/free (system malloc/free) to allocate the heap that we use for testing our malloc and free. Basically, when we did that, run-malloc.c test would get this valgrind warning: ==3869== Invalid read of size 8 ==3869== at 0x4C2A706: memcpy (mc_replace_strmem.c:838) ==3869== by 0x40323F: __realloc (malloc.c:69) ==3869== by 0x405815: main (run-malloc.c:142) Which was because in realloc(), when we have to relocate the allocated bit of memory, we memcpy the contents of the old location into the new one. The current mem_size() implementation *included* struct alloc_hdr which mean that we were copying allocated size + sizeof(struct alloc_hdr) from the returned pointer. This meant we read sizeof(struct alloc_hdr) past the end of the allocation... which will pretty much always be harmless, just get random junk in the realloc()ed space. i.e. we would memcpy() 64+16 (80) bytes from the malloc(64) space to the realloc(128) space, which is, obviously, 16 bytes more than we should. IF we had some memory after a region that would make us explode if we read, then we'd explode around the realloc() call... which would not be so good. After a bit of a code audit I'm pretty sure this isn't going to actually hurt us anywhere... or, at least, I hope not... The fix is simple: fix mem_size() to subtract sizeof(struct alloc_hdr) from the returned value. This should be okay with the other test case that checks mem_size() result and there are no other mem_size() callers. Signed-off-by: Stewart Smith Acked-by: Rusty Russell

Initial commit of Open Source release

2014-07-02T05:36:20+00:00

Signed-off-by: Benjamin Herrenschmidt