talos-skiboot/core/test, branch master

core: Fix mismatched names between reserved memory nodes & properties

2018-02-21T02:28:08+00:00

OPAL exposes reserved memory regions through the device tree in both new (nodes) and old (properties) formats. However, the names used for these don't match - we use a generated cell address for the nodes, but the plain region name for the properties. This change, heavily based on code from Oliver O'Halloran , reworks the dt-generation code to firstly generate the new-format nodes, then uses those same names to generate the property data. Reported-by: Deb McLemore CC: Oliver O'Halloran Signed-off-by: Jeremy Kerr [stewart: fix test case] Signed-off-by: Stewart Smith

core/device.c: Fix dt_find_compatible_node

2018-02-13T07:30:10+00:00

dt_find_compatible_node() and dt_find_compatible_node_on_chip() are used to find device nodes under a parent/root node with a given compatible property. dt_next(root, prev) is used to walk the child nodes of the given parent and takes two arguments - root contains the parent node to walk whilst prev contains the previous child to search from so that it can be used as an iterator over all children nodes. The first iteration of dt_find_compatible_node(root, prev) calls dt_next(root, root) which is not a well defined operation as prev is assumed to be child of the root node. The result is that when a node contains no children it will start returning the parent nodes siblings until it hits the top of the tree at which point a NULL derefence is attempted when looking for the root nodes parent. Dereferencing NULL can result in undesirable data exceptions during system boot and untimely non-hilarious system crashes. dt_next() should not be called with prev == root. Instead we add a check to dt_next() such that passing prev = NULL will cause it to start iterating from the first child node (if any). Also add a unit test for this case to run-device.c. Signed-off-by: Alistair Popple Signed-off-by: Stewart Smith

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

make check: Make valgrind optional

2017-12-18T23:58:32+00:00

To (slightly) lower the barrier for contributions, we can make valgrind optional with just a small amount of plumbing. This allows make check to run successfully without valgrind. Signed-off-by: Michael Ellerman Signed-off-by: Stewart Smith

nvram: Fix 'missing' nvram on FSP systems.

2017-12-01T05:45:45+00:00

commit ba4d46fdd9eb ("console: Set log level from nvram") wants to read from NVRAM rather early. This works fine on BMC based systems as nvram_init() is actually synchronous. This is not true for FSP systems and it turns out that the query for the console log level simply queries blank nvram. The simple fix is to wait for the NVRAM read to complete before performing any query. Unfortunately it turns out that the fsp-nvram code does not inform the generic NVRAM layer when the read is complete, rather, it must be prompted to do so. This patch addresses both these problems. This patch adds a check before the first read of the NVRAM (for the console log level) that the read has completed. The fsp-nvram code has been updated to inform the generic layer as soon as the read completes. The old prompt to the fsp-nvram code has been removed but a check to ensure that the NVRAM has been loaded remains. It is conservative but if the NVRAM is not done loading before the host is booted it will not have an nvram device-tree node which means it won't be able to access the NVRAM at all, ever, even after the NVRAM has loaded. Signed-off-by: Cyril Bur Signed-off-by: Stewart Smith

core/bitmap: Test bitmap foreach functions

2017-11-28T05:07:00+00:00

Signed-off-by: Stewart Smith

core/test/run-msg: don't depend on unittest mem layout

2017-08-24T04:09:31+00:00

In the world of unit tests all "RAM" is valid Signed-off-by: Stewart Smith

core/test/run-device: fix memory leak on exit

2017-08-24T02:59:15+00:00

Shuts LeakSanitizer up Signed-off-by: Stewart Smith

test/mem_region: fix incorrect ibm,os-reserve region length

2017-08-24T02:59:15+00:00

We were reserving all of memory up to the heap, which is fine *unless* the system libc chooses to allocate something in that block of memory that we use, which means we have overlapping regions and general pain. This should fix failing unit tests on some systems (e.g. Debian) Signed-off-by: Stewart Smith

Fix mem leak in core/test/run-time-utils

2017-08-23T00:58:55+00:00

Fixes the following LeakSanitizer errors: ================================================================= ==32426==ERROR: LeakSanitizer: detected memory leaks Direct leak of 56 byte(s) in 1 object(s) allocated from: #0 0x7fd94a1fa850 in malloc (/lib64/libasan.so.4+0xde850) #1 0x4014d4 in main core/test/run-time-utils.c:30 #2 0x7fd94904c509 in __libc_start_main (/lib64/libc.so.6+0x20509) Direct leak of 8 byte(s) in 1 object(s) allocated from: #0 0x7fd94a1fa850 in malloc (/lib64/libasan.so.4+0xde850) #1 0x4014f0 in main core/test/run-time-utils.c:32 #2 0x7fd94904c509 in __libc_start_main (/lib64/libc.so.6+0x20509) Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x7fd94a1fa850 in malloc (/lib64/libasan.so.4+0xde850) #1 0x4014e2 in main core/test/run-time-utils.c:31 #2 0x7fd94904c509 in __libc_start_main (/lib64/libc.so.6+0x20509) Signed-off-by: Stewart Smith