From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8475C433E0 for ; Fri, 12 Jun 2020 07:56:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 808B7207D8 for ; Fri, 12 Jun 2020 07:56:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="anJiOowG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726371AbgFLH4b (ORCPT ); Fri, 12 Jun 2020 03:56:31 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:33688 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726396AbgFLH4a (ORCPT ); Fri, 12 Jun 2020 03:56:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591948589; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LNbUY1q6FIZ97hLXxGpuj36BUNMuCI5VduaUjfayv64=; b=anJiOowGuHxkszPc3psthCkrAxgjmzg2Eh5dQXtT4BHFWBW7iE13ORo+f2KUtoZSuuhJeO Cq6BVDvd0TgI/UWdm12zuhr7CX02s0V+G7Z4LPRFEtuRzonQBNQGA+p/4gMHlRSJ9aYlMh UgqUIa1nPoXZNEdfP2mWEpBg8IUZPQg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-501-cab5DlpeObi7zj79e2LdIQ-1; Fri, 12 Jun 2020 03:56:23 -0400 X-MC-Unique: cab5DlpeObi7zj79e2LdIQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 796D7872FE2; Fri, 12 Jun 2020 07:56:21 +0000 (UTC) Received: from krava (unknown [10.40.192.78]) by smtp.corp.redhat.com (Postfix) with ESMTP id 461295C1B2; Fri, 12 Jun 2020 07:56:15 +0000 (UTC) Date: Fri, 12 Jun 2020 09:56:14 +0200 From: Jiri Olsa To: Ilya Leoshkevich Cc: Heiko Carstens , Vasily Gorbik , netdev@vger.kernel.org, bpf@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , John Fastabend , KP Singh , Frantisek Hrbata , Yauheni Kaliuta Subject: Re: [RFC] .BTF section data alignment issue on s390 Message-ID: <20200612075614.GA1885974@krava> References: <20200611205040.GA1853644@krava> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Fri, Jun 12, 2020 at 12:46:13AM +0200, Ilya Leoshkevich wrote: > On Thu, 2020-06-11 at 22:50 +0200, Jiri Olsa wrote: > > hi, > > we're hitting a problem on s390 with BTF data alignment. > > > > When running simple test, we're getting this message from > > verifier and console: > > > > bpf_common.c:91: BROK: Failed verification: in-kernel BTF is > > malformed > > [ 41.545572] BPF:Total section length too long > > > > > > AFAICS it happens when .BTF section data size is not an even number > > ;-) > > > > DISCLAIMER I'm quite ignorant of s390x arch details, so most likely > > I'm > > totally wrong and perhaps missing something important and there's > > simple > > explanation.. but here's what got me here: > > > > > > ... so BTF data is placed in .BTF section via linker script: > > > > .BTF : AT(ADDR(.BTF) - LOAD_OFFSET) > > { \ > > __start_BTF = > > .; \ > > *(.BTF) > > \ > > __stop_BTF = > > .; \ > > } > > > > > > and the .BTF data size in btf_parse_vmlinux is computed as: > > > > btf->data_size = __stop_BTF - __start_BTF; > > > > > > this computation is compiled as: > > > > 00000000002aeb20 : > > ... > > 2aeb8a: larl %r1,cda3ac <__start_BTF+0x2084a8> # > > loads r1 with end > > 2aeb90: larl %r2,ad1f04 <__start_BTF> # > > loads r2 with start > > 2aeb96: sgr %r1,%r2 # > > substract r1 - r2 > > > > > > having following values for start/stop_BTF symbols: > > > > # nm ./vmlinux | grep __start_BTF > > 0000000000ad1f04 R __start_BTF > > # nm ./vmlinux | grep __stop_BTF > > 0000000000cda3ad R __stop_BTF > > > > -> the BTF data size is 0x2084a9 > > > > > > but as you can see the instruction that loads the 'end' symbol: > > > > larl %r1,cda3ac <__start_BTF+0x2084a8> > > > > > > is loading '__start_BTF + 0x2084a8', which is '__stop_BTF - 1' > > > > > > From spec it seems that larl instruction's argument must be even > > number ([1] page 7-214): > > > > 2. For LOAD RELATIVE LONG, the second oper-and must > > be aligned > > on an integral boundary cor-responding to the operand’s > > size. > > > > > > I also found an older bug complaining about this issue [2]: > > > > ... > > larl instruction can only load even values - instructions on > > s390 are 2-byte > > aligned and the instruction encodes offset to the target in > > 2-byte units. > > ... > > The GNU BFD linker for s390 doesn't bother to check if > > relocations fit or are > > properly aligned. > > ... > > > > > > I tried to fix that aligning the end to even number, but then > > btf_check_sec_info logic needs to be adjusted as well, and > > probably other places as well.. so I decided to share this > > first.. because it all seems wrong ;-) > > > > thoughts? thanks, > > jirka > > > > > > [1] http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr008.pdf > > [2] https://sourceware.org/bugzilla/show_bug.cgi?id=18960 > > > Hi Jiri, > > Actually I recently ran into it myself on Debian, and I believe your > analysis is correct :-) The only thing to add to it is that the > compiler emits the correct instruction (if you look at the .o file), > it's linker that messes things up. > > The linker bug in question is [1]. > > I opened [2] to Debian folks, and I believe that other important > distros (RH, SUSE, Ubuntu) have this fixed already. > > Which distro are you using? I'm on RHEL ;-) I wonder why that fix was missed, I'll follow up on that with our binutils guys thanks a lot for the info, jirka > > Best regards, > Ilya > > [1] > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e6213e09ed0e > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961736 >