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 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 128E4C2BA83 for ; Sun, 9 Feb 2020 18:32:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D404A207FF for ; Sun, 9 Feb 2020 18:32:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Y0/5tjKL" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727409AbgBISc4 (ORCPT ); Sun, 9 Feb 2020 13:32:56 -0500 Received: from mail-qk1-f196.google.com ([209.85.222.196]:45218 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727388AbgBISc4 (ORCPT ); Sun, 9 Feb 2020 13:32:56 -0500 Received: by mail-qk1-f196.google.com with SMTP id a2so3884510qko.12; Sun, 09 Feb 2020 10:32:55 -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=FwnS7raatQida7H2CFe9qp4MAjUyBdHcORgJ6PWgqUw=; b=Y0/5tjKL7sgveyW9gFjK83XEW6pBvdPc7r2ljDKNaFdD0C5k4z04v/XHmxnIcNqlHt R1FZqLK1nN3M/HDZ39GErlxZrRsFjvjiqEzuf70TZ1IWJ3wOa08OGIXoXCJQOhDyD6Wv K8fFjtpOx2GgKTNxIBdkN07b3mzdrwgueEzNSEPjB7XiV3BhyaF6NJdOLLQ7GQUAxRzy Lc4uBrl9ILU3JyCeQw5s7r8dlEpTQok8sNQBZOxYaCqydnqlVR1ARdAKzo8Kyz/wDDEO 7Cq+5hr+JRPZYIIhKnl8CwEfyeKN91wu15vDylKtSVM5gPZsIXfAISXQgW8m9LxknXHp v8WA== 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=FwnS7raatQida7H2CFe9qp4MAjUyBdHcORgJ6PWgqUw=; b=l1IqnaOoiEtXGeqmtOiDqhHrSbXthF1Jvj3OUkjr0oQLynaxjAUvU3Fo4gB4YOffZd ZzsqpWVmuv+qgAgqvuXkGghkTWKpWBfUWQ7HIVGW6isWt0BiVzJbFw3Mxa1unNGeu1s2 dw5wFV7qwaA1EXi+Tms1grIZxD+uajV+CFME4zOHAjtTY1Wc34gYlVV0I7w20k+Mglzw u9rden5iYsnWQg7Ku7iwPBED4STVmXNUwq2EQ79J3/Lc4ixUK8O0XgtyEIuPtuST9VKR /SgSheUs1m/DZ6anQhL0IIltpLxbBL45qwWQlBkSkyi951WGcGui0A91AxDI/4gdqNpQ sMvw== X-Gm-Message-State: APjAAAX89mjrC0rJEWFXAzg6wI5bJK/bXcNDSCbo9oQ7rBqOVksRxeN2 Cbi+PDWMKSWJ20ggcZNiP4/TZaYh/qME6yk1QDA= X-Google-Smtp-Source: APXvYqzP1RxfdsKNw9pW8Ehjii9Jtw2/sFYVRAqs2QF8LyqIifQ9oDd/1PxgSaZ9JptPmg/yJPgXwA1OFrk95pqGvno= X-Received: by 2002:a37:785:: with SMTP id 127mr7831977qkh.437.1581273174941; Sun, 09 Feb 2020 10:32:54 -0800 (PST) MIME-Version: 1.0 References: <20191212013521.1689228-1-andriin@fb.com> In-Reply-To: From: Andrii Nakryiko Date: Sun, 9 Feb 2020 10:32:43 -0800 Message-ID: Subject: Re: [PATCH bpf-next 0/4] Fix perf_buffer creation on systems with offline CPUs To: Naresh Kamboju Cc: Andrii Nakryiko , Greg Kroah-Hartman , Sasha Levin , bpf , Netdev , Alexei Starovoitov , Daniel Borkmann , Kernel Team , linux- stable , lkft-triage@lists.linaro.org, Arnaldo Carvalho de Melo , Leo Yan 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 Sun, Feb 9, 2020 at 9:18 AM Naresh Kamboju wrote: > > On Thu, 12 Dec 2019 at 07:05, Andrii Nakryiko wrote: > > > > This patch set fixes perf_buffer__new() behavior on systems which have some of > > the CPUs offline/missing (due to difference between "possible" and "online" > > sets). perf_buffer will create per-CPU buffer and open/attach to corresponding > > perf_event only on CPUs present and online at the moment of perf_buffer > > creation. Without this logic, perf_buffer creation has no chances of > > succeeding on such systems, preventing valid and correct BPF applications from > > starting. > > > > Andrii Nakryiko (4): > > libbpf: extract and generalize CPU mask parsing logic > > selftests/bpf: add CPU mask parsing tests > > libbpf: don't attach perf_buffer to offline/missing CPUs > > perf build failed on stable-rc 5.5 branch. > > libbpf.c: In function '__perf_buffer__new': > libbpf.c:6159:8: error: implicit declaration of function > 'parse_cpu_mask_file'; did you mean 'parse_uint_from_file'? > [-Werror=implicit-function-declaration] > err = parse_cpu_mask_file(online_cpus_file, &online, &n); > ^~~~~~~~~~~~~~~~~~~ > parse_uint_from_file > libbpf.c:6159:8: error: nested extern declaration of > 'parse_cpu_mask_file' [-Werror=nested-externs] > > build log, > https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.5/DISTRO=lkft,MACHINE=hikey,label=docker-lkft/11/console > Thanks for reporting! These changes depend on commit 6803ee25f0ea ("libbpf: Extract and generalize CPU mask parsing logic"), which weren't backported to stable. Greg, can you please pull that one as well? Thanks! > -- > Linaro LKFT > https://lkft.linaro.org