Fixes for compilation with -Werror#2
Open
frediz wants to merge 3 commits intojk-ozlabs:ubuntu/utopicfrom
Open
Conversation
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Will make an opal-gard package .deb file which just contains the gard utility. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
On Debian/Ubuntu, additionnal compilation flags are added such as -Werror which make compilation fail. So : - checking function return codes so that the compilation doesn't fail. - moving 'largest' variable so that gcc always sees it with a value.
jk-ozlabs
force-pushed
the
ubuntu/utopic
branch
from
4225d75 to
d7b284c
Compare
jk-ozlabs
pushed a commit
that referenced
this pull request
May 15, 2017
This ends up being harmless bug due to memory layout.
$ ./pflash -F ~/op-build/output/images/firestone.pnor -i
==31829==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00000062f0
80 at pc 0x410226 bp 0x7ffedba9c950 sp 0x7ffedba9c948
WRITE of size 8 at 0x00000062f080 thread T0
#0 0x410225 in file_get_info (/home/stewart/skiboot/external/pflash/pflash+0
x410225)
#1 0x40d832 in blocklevel_get_info (/home/stewart/skiboot/external/pflash/pf
lash+0x40d832)
#2 0x401f0c in main (/home/stewart/skiboot/external/pflash/pflash+0x401f0c)
open-power#3 0x7fc77439ab44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21
b44)
open-power#4 0x403884 (/home/stewart/skiboot/external/pflash/pflash+0x403884)
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
jk-ozlabs
pushed a commit
that referenced
this pull request
Oct 3, 2017
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 <stewart@linux.vnet.ibm.com>
jk-ozlabs
pushed a commit
that referenced
this pull request
Oct 3, 2017
…nt', which requires 8 byte alignment
UBSan caught this:
hdata/test/../iohub.c:83:2: runtime error: load of misaligned address 0x7f1dc7b0210a for type 'long unsigned int', which requires 8 byte alignment
0x7f1dc7b0210a: note: pointer points here
31 4c 58 08 31 00 04 01 00 30 00 42 50 46 02 00 00 78 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
#0 0x41470a in io_get_lx_info hdata/test/../iohub.c:83
#1 0x41759f in io_add_p8_cec_vpd hdata/test/../iohub.c:450
#2 0x417d35 in io_parse_fru hdata/test/../iohub.c:538
open-power#3 0x41812a in io_parse hdata/test/../iohub.c:600
open-power#4 0x425aa2 in parse_hdat hdata/test/../spira.c:1337
open-power#5 0x43d9f8 in main hdata/test/hdata_to_dt.c:358
open-power#6 0x7f1dcb868509 in __libc_start_main (/lib64/libc.so.6+0x20509)
open-power#7 0x4019e9 in _start (/home/stewart/skiboot/hdata/test/hdata_to_dt+0x4019e9)
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
jk-ozlabs
pushed a commit
that referenced
this pull request
Oct 3, 2017
LeakSanitizer spotted this:
Direct leak of 131072 byte(s) in 1 object(s) allocated from:
#0 0x7fb99e42b850 in malloc (/lib64/libasan.so.4+0xde850)
#1 0x408612 in main libflash/test/test-flash.c:380
#2 0x7fb99d27d509 in __libc_start_main (/lib64/libc.so.6+0x20509)
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
jk-ozlabs
pushed a commit
that referenced
this pull request
Oct 3, 2017
LeakSanitizer caught this with libflash/test/test-flash.c:
Direct leak of 4096 byte(s) in 1 object(s) allocated from:
#0 0x7f72546ee850 in malloc (/lib64/libasan.so.4+0xde850)
#1 0x405ff0 in flash_init libflash/test/../libflash.c:830
#2 0x408632 in main libflash/test/test-flash.c:382
open-power#3 0x7f7253540509 in __libc_start_main (/lib64/libc.so.6+0x20509)
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
jk-ozlabs
pushed a commit
that referenced
this pull request
Oct 3, 2017
==8304==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4096 byte(s) in 1 object(s) allocated from:
#0 0x7f70eda8f850 in malloc (/lib64/libasan.so.4+0xde850)
#1 0x408ba0 in main libflash/test/test-blocklevel.c:298
#2 0x7f70ec8e1509 in __libc_start_main (/lib64/libc.so.6+0x20509)
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
jk-ozlabs
pushed a commit
that referenced
this pull request
Mar 1, 2019
A bad GPU or other condition may leave us with a subset of links that never get initialized. If an ATSD is sent to one of those bricks, it will never complete, leaving us waiting forever for a response: watchdog: BUG: soft lockup - CPU#23 stuck for 23s! [acos:2050] ... Modules linked in: nvidia_uvm(O) nvidia(O) CPU: 23 PID: 2050 Comm: acos Tainted: G W O 4.14.0 #2 task: c0000000285cfc00 task.stack: c000001fea860000 NIP: c0000000000abdf0 LR: c0000000000acc48 CTR: c0000000000ace60 REGS: c000001fea863550 TRAP: 0901 Tainted: G W O (4.14.0) MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 28004484 XER: 20040000 CFAR: c0000000000abdf4 SOFTE: 1 GPR00: c0000000000acc48 c000001fea8637d0 c0000000011f7c00 c000001fea863820 GPR04: 0000000002000000 0004100026000000 c0000000012778c8 c00000000127a560 GPR08: 0000000000000001 0000000000000080 c000201cc7cb7750 ffffffffffffffff GPR12: 0000000000008000 c000000003167e80 NIP [c0000000000abdf0] mmio_invalidate_wait+0x90/0xc0 LR [c0000000000acc48] mmio_invalidate.isra.11+0x158/0x370 ATSDs are only sent to bricks which have a valid entry in the XTS_BDF table. So to prevent the hang, don't set NPU2_XTS_BDF_MAP_VALID unless we make it all the way to creating a context for the BDF. Signed-off-by: Reza Arbab <arbab@linux.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
jk-ozlabs
pushed a commit
that referenced
this pull request
Mar 1, 2019
The NPU2{DBG,INF,ERR} macros use "NPU%d" as a prefix to identify messages
relating to a particular NPU.
It's slightly confusing to have per-NPU messages prefixed with "NPU0" or
"NPU1" and NPU-generic messages prefixed with "NPU2". On some future system
we could potentially have a NPU #2 in which case it'd be really confusing.
Use NPU rather than NPU2 for NPU-generic log messages. There's no risk of
confusion with the original npu.c code since that's only for P8.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Acked-by: Reza Arbab <arbab@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On Debian/Ubuntu, additionnal compilation flags are added such as -Werror which make
compilation fail. So :