Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752124AbdHHIJ6 (ORCPT ); Tue, 8 Aug 2017 04:09:58 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:58415 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751464AbdHHIJz (ORCPT ); Tue, 8 Aug 2017 04:09:55 -0400 Subject: Re: Fwd: struct pt_regs missing in /usr/include/ tree for eBPF program compile To: Daniel Borkmann Cc: ast@kernel.org, Hendrik Brueckner , Martin Schwidefsky , Heiko Carstens , linux-kernel@vger.kernel.org, Michael Holzheu , davem@davemloft.net, yhs@fb.com References: <49c5e39b-a7d9-1e2d-24ec-57852f7d1e51@linux.vnet.ibm.com> <598492A6.10707@iogearbox.net> From: Thomas-Mich Richter Organization: IBM LTC Date: Tue, 8 Aug 2017 10:09:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <598492A6.10707@iogearbox.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-IE Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 17080808-0008-0000-0000-0000048B32E0 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17080808-0009-0000-0000-00001E1A4891 Message-Id: <27d94cf9-f953-92c2-d50b-e0ce21fc4886@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-08-08_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708080131 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4503 Lines: 104 On 08/04/2017 05:28 PM, Daniel Borkmann wrote: > From: Thomas-Mich Richter > Date: Wed, Aug 2, 2017 at 1:22 AM > [...] >> I work on the perf tool and its bpf support for IBM s390 and came across a >> strange issue compiling tools/testing/selftests/bpf/test_verifier.c on s390x. >> >> This is the compile error: >> gcc -Wall -O2 -I../../../include/uapi -I../../../lib >> -I../../../../include/generated >> -DHAVE_GENHDR -I../../../include test_verifier.c >> /root/linux-devel/tools/testing/selftests/bpf/libbpf.a -lcap -lelf -o >> /root/linux-devel/tools/testing/selftests/bpf/test_verifier >> In file included from test_verifier.c:63:0: >> ../../../include/uapi/linux/bpf_perf_event.h:14:17: error: field ‘regs’ has >> incomplete type struct pt_regs regs; > > I actually came across the same issue today on s390 > while testing for something else. > >> This shows up in test case "unpriv: spill/fill of different pointers ldx" >> at line 1811. >> This issue is located in file /usr/include/linux/bpf_perf_event.h which is a >> copy of the linux kernels include/uapi/linux/bpf_perf_event.h. >> >> It contains: >> struct bpf_perf_event_data { >> struct pt_regs regs; >> __u64 sample_period; >> }; > > Yeah, correct. > >> On s390 struct pt_regs is not exported to user space and does not appear >> anywhere in /usr/include. >> How about other architectures beside Intel? >> As far as I know >> 1. the struct pt_regs contains only kernel registers, no user space registers? >> 2. Is part of the kernel API and should not be exported at all? > > Looking into the tree, it appears that the following archs > export a definition of struct pt_regs as uapi typically in > arch/*/include/uapi/asm/ptrace.h: x86, sparc, power, mips, > microblaze, alpha, unicore32, parisc, score, sh, mn10300, > tile, m68k, m32r, ia64, hexagon, h8300, frv, cris, c6x. > And for these I couldn't find it: s390, arc, arm64, nios2. > > Anyone knows if there's any guidance on whether they must > be exported or not? It appears at least the majority of > archs is exporting them in one way or another. > > Looking at 2dbb4c05d048 ("bpf/samples: Fix PT_REGS_IP on > s390x and use it") and d912557b3460 ("samples: bpf: enable > trace samples for s390x"), this was added by Michael for > the programs themselves, which were using kernel headers > for walking structs in BPF tracing programs, so a bit > unrelated to the uapi issue actually, but given the > test_verifier has couple of test cases containing pt_regs, > they should probably do the same thing and be using kernel > headers given tracing programs inspect kernel-internal > data structures typically (see BPF tracing samples). I have looked at 2dbb4c05d048 ("bpf/samples: Fix PT_REGS_IP on > s390x and use it"). This usage scenario is a bit different. True it requires access to individual registers via context pointer stored in register R1. The context pointer is of type struct bpf_perf_event_data and the first member is of type struct pt_regs. The big difference is the compilation of samples/bpf/sampleip_kern.c. It is built inside the kernel root directory .../linux and includes ./arch/s390/include/asm/ptrace.h (which defines struct pt_regs). This is different from compiling tools/testing/selftests/bpf/test_verifier.c. This compilation does not happen inside the kernel root directory ..../linux and thus needs some type of struct pt_regs definition in user space. Interestingly the test_verifier.c only needs the size of the struct pt_regs. Both failing lines of code use offset_of: BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -(__s32)offsetof(struct bpf_perf_event_data, sample_period) - 8)), which in fact subtracts the sizeof (struct pt_regs) from R2. > > Now, I would like to avoid going down that road to pull > in kernel internal headers into test_verifier.c, could > we instead add a bpf_ptregs.h helper in tools/testing/selftests/bpf/, > where s390 and arm64 would put a definition to fallback when > otherwise not available? Admittedly, it's a bit of a hack > if exporting them is not an option, but 'normal' tracing > progs would consult kernel headers anyway. Thoughts? > -- Thomas Richter, Dept 3303, IBM LTC Boeblingen Germany -- Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294