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=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 EA819C282C4 for ; Tue, 12 Feb 2019 20:43:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BD769222BE for ; Tue, 12 Feb 2019 20:43:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731949AbfBLUnf (ORCPT ); Tue, 12 Feb 2019 15:43:35 -0500 Received: from mail-wr1-f67.google.com ([209.85.221.67]:44715 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727012AbfBLUnf (ORCPT ); Tue, 12 Feb 2019 15:43:35 -0500 Received: by mail-wr1-f67.google.com with SMTP id v16so25962wrn.11; Tue, 12 Feb 2019 12:43:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+GyOQMVuL0gjZ03ucSnVxfot24VF7SR8Dp0ykkVA2gk=; b=NGeSJpNE+rJHGhSHvAzRPRCD/Lq/f0BLF2k7MxLnjDmH4Kxx79IP9LePrKvAuaSdF1 /x+KnvApy9oqPXkMFDcIciLMgV9PbwFrHWIZyvkXPwCEooiecLbvB3OVrdNypVOQqknk jKfF1J0XFlE0gIkYBdNc9vQSP/+hiLARTEsRdJDLhtWKnPsZoCbluEFzyyeZ/+D57BDK tFvFMvqkYlhCxbFTGgNpizBtag6yCQ92Vba0DMfD9z+PxNIl5ejl/J6LLAv4kUtZnSSE oT+6hgxfrq+TSOZyfI1OS/PBRjD9P9tgvfOU+XT4BX6b0XMYoBWxiEOv4lineSbwStye Wilg== X-Gm-Message-State: AHQUAua1qupQ0cJf4UuOzRUYqj5qRDD6ajkUPGv8waUzR+KwgrqfVEbQ ZgecFn6pwhsgLfhOm9OPrfVKYvp9K+JiN55Aorc= X-Google-Smtp-Source: AHgI3IZ+PzXdpU4KvvIvmhIQkgBr8CaMkcA1g4liHhtWB/57ZpuU37Wyzb/xM7p5gEEDvhl6y6pXehHkSMc2vIsStFY= X-Received: by 2002:adf:b7c1:: with SMTP id t1mr4156687wre.248.1550004213312; Tue, 12 Feb 2019 12:43:33 -0800 (PST) MIME-Version: 1.0 References: <20190212004729.535-1-joe@wand.net.nz> <20190212004729.535-5-joe@wand.net.nz> <20190212050113.qkryxb34vpnst6w6@ast-mbp> In-Reply-To: <20190212050113.qkryxb34vpnst6w6@ast-mbp> From: Joe Stringer Date: Tue, 12 Feb 2019 12:43:21 -0800 Message-ID: Subject: Re: [PATCH bpf-next 4/4] selftests/bpf: Test static data relocation To: Alexei Starovoitov Cc: Joe Stringer , bpf@vger.kernel.org, netdev , Daniel Borkmann , ast@kernel.org Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Feb 11, 2019 at 9:01 PM Alexei Starovoitov wrote: > > On Mon, Feb 11, 2019 at 04:47:29PM -0800, Joe Stringer wrote: > > Add tests for libbpf relocation of static variable references into the > > .data and .bss sections of the ELF. > > > > Signed-off-by: Joe Stringer > ... > > +#define __fetch(x) (__u32)(&(x)) > > + > > +static __u32 static_bss = 0; /* Reloc reference to .bss section */ > > +static __u32 static_data = 42; /* Reloc reference to .data section */ > > + > > +/** > > + * Load a u32 value from a static variable into a map, for the userland test > > + * program to validate. > > + */ > > +SEC("static_data_load") > > +int load_static_data(struct __sk_buff *skb) > > +{ > > + __u32 key, value; > > + > > + key = 0; > > + value = __fetch(static_bss); > > If we proceed with this approach we will not be able to add support > for normal 'value = static_bss;' C code in the future. Hmm, completely agree that breaking future use of standard code is a non-starter. Digging around a bit more, I think I could drop the .bss patch/code here and still end up with something that will work for my use case. Just need to ensure that all template values are non-zero when run through the compiler. > Let's figure out the way to do it right from the start. > Support for global and static variables is must have feature to add asap, > but let's not cut the corner like this. > We did such hacks in the past and every time it came back to bite us. Do you see any value in having incremental support in libbpf that could be used as a fallback for older kernels like in patch #2 of this series? I could imagine libbpf probing kernel support for global/static variables and attempting to handle references to .data via some more comprehensive mechanism in-kernel, or falling back to this approach if it is not available.