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.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 03DEFC432C0 for ; Wed, 27 Nov 2019 18:55:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CEC1620715 for ; Wed, 27 Nov 2019 18:55:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="vB0sSz4Y" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727327AbfK0Szq (ORCPT ); Wed, 27 Nov 2019 13:55:46 -0500 Received: from mail-lj1-f194.google.com ([209.85.208.194]:39101 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727026AbfK0Szq (ORCPT ); Wed, 27 Nov 2019 13:55:46 -0500 Received: by mail-lj1-f194.google.com with SMTP id e10so16467616ljj.6; Wed, 27 Nov 2019 10:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2fxjJCT0Umg1tlImdCr24IAuRODORNzU/xb+VTe56+s=; b=vB0sSz4Y3YAKbLheatrpW/t/+AmJKdS3Xw309nuiHS2dDapGmmIvkxmmVJh+fXi5Dg gdqWAXpnG/oR+Olt4234Gf5zH4vB13ma3SqQN0iXy4AE2P9dH3V+HtXEnDYvq9Edo7vK fUeKEGhOFQz7TvHBuTvANCEQRi+7ZpjHI0+yBPMe8yYxAHb/Ffti/Tw0t9UnbJkP2ywc mMWN2BG+lux1uXbxUvTFo+CNncF3DbNvkL27neD5AqN7+YEPUyyYUX7tDGW+cGnrc7qo SBolkr047wGfIw1vOOxwhEhJ+ovL1XUgLtRjnc409Hae1rHQr3u5Bh0bYzV4u0nu/YLE DcHw== 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=2fxjJCT0Umg1tlImdCr24IAuRODORNzU/xb+VTe56+s=; b=L10slxmjE/emQtYA6ApDAFimi6wml2jJDzfzE+wF/otRwxNtM7b009ifGRt411tr/W 3/tR8kowcdPwvcakpyku/EDIV42uPGhMOYpu/3hAv/kSdsD9Y/NXYCeLsUIrxMuBZcg3 taorUurwidMSdZianuy5F7dZtUXLx90LmQZ5WDxwrj3kqaBbLlqd+z9GguYIiLnVcWac po2FRYUQh6F4QiPzwvR39Et5l3weC5Q0XAM4Wk7MgZwSr1FyONVx9VmiyHJ57AVvTBGW 2WhGXrO2CvhafdeljilXDNNNIzAT39bVWMJv4YxoubAhHyRC+cjs4B0FhvAUrhuzCBwX m/PQ== X-Gm-Message-State: APjAAAUoC13vAuOTlbFn1lmbPcmG8ENbrZt1nUqCzSF0tpHRZULz6NoX 3qXjSORuzeCaDRLZd2FWDLaBQGVAzUc3ubOowK8= X-Google-Smtp-Source: APXvYqy2+d9ffng76tXB3kAzE96084n2upvu0rGFZzj8xbsKSZjCFw7TgmR1zGNmC+E4lMOzs72DmDKZeBUnT173n50= X-Received: by 2002:a2e:970a:: with SMTP id r10mr32610245lji.142.1574880942555; Wed, 27 Nov 2019 10:55:42 -0800 (PST) MIME-Version: 1.0 References: <20191126190450.GD29071@kernel.org> <20191126221018.GA22719@kernel.org> <20191126221733.GB22719@kernel.org> <20191126231030.GE3145429@mini-arch.hsd1.ca.comcast.net> <20191126155228.0e6ed54c@cakuba.netronome.com> <20191127013901.GE29071@kernel.org> <20191127134553.GC22719@kernel.org> <20191127184526.GB4063@kernel.org> In-Reply-To: <20191127184526.GB4063@kernel.org> From: Alexei Starovoitov Date: Wed, 27 Nov 2019 10:55:31 -0800 Message-ID: Subject: Re: [PATCH] libbpf: Use PRIu64 for sym->st_value to fix build on 32-bit arches To: Arnaldo Carvalho de Melo Cc: Andrii Nakryiko , Jakub Kicinski , Stanislav Fomichev , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Andrii Nakryiko , Adrian Hunter , Alexei Starovoitov , Daniel Borkmann , Jiri Olsa , Martin KaFai Lau , Namhyung Kim , bpf , Networking , linux-perf-users@vger.kernel.org, Linux Kernel Mailing List , Quentin Monnet Content-Type: text/plain; charset="UTF-8" Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Wed, Nov 27, 2019 at 10:45 AM Arnaldo Carvalho de Melo wrote: > > Em Wed, Nov 27, 2019 at 08:39:28AM -0800, Alexei Starovoitov escreveu: > > On Wed, Nov 27, 2019 at 5:45 AM Arnaldo Carvalho de Melo > > wrote: > > > > > > Another fix I'm carrying in my perf/core branch, > > > Why in perf/core? > > I very much prefer all libbpf patches to go via normal route via bpf/net trees. > > We had enough conflicts in this merge window. Let's avoid them. > > Humm, if we both carry the same patch the merge process can do its magic > and nobody gets hurt? Besides these are really minor things, no? I thought so too, but learned the hard lesson recently. We should try to avoid that as much as possible. Andrii's is fixing stuff in the same lines: https://patchwork.ozlabs.org/patch/1201344/ these two patches will likely conflict. I'd rather have them both in bpf tree. What is the value for this patch in perf tree? To fix the build on 32-bit arches, right? But how urgent is it? Can you wait few days until this one and other libbpf fixes land via bpf/net trees?