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=-2.8 required=3.0 tests=BAYES_00,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 A0493C433B4 for ; Wed, 5 May 2021 04:43:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7422A610E6 for ; Wed, 5 May 2021 04:43:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231582AbhEEEoA (ORCPT ); Wed, 5 May 2021 00:44:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229895AbhEEEn7 (ORCPT ); Wed, 5 May 2021 00:43:59 -0400 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D3DCC061574; Tue, 4 May 2021 21:43:02 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id z9so705798lfu.8; Tue, 04 May 2021 21:43:02 -0700 (PDT) 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=i6tfWMiqn6tTusu+83OD8TRFhIHM3EtAwOkc3hLLH0g=; b=XktYorfIIBfBLTBr5zmtIeIvOzwJojU7pduKcNznDQdlv0kcRrBH2a6sKjf7Me15gO MEU0EVh7GGFr31PXSGqAw8T/jRCMgfoFft73Mr8bC59gHHbwba0NMZOWtHRGQIEq1hLY bXW7RweE1fOsEeAGSsFiZsv83INrYCLRjJVZE6QMts0tCKjAApvUZae8jqLDbXI5TQAm DEWyYCOriUUUYmuISjQucr6HmYC98sikOD0lLpYYsYGpFuoa+RM1w9Il9X98KDXu+o+G zc7ufPY1cLiyUgeg1zI3wekirkzqrf7fJs5KvbTo+62a+QDdheurRlUkou0oh/sUTO3S hr4A== 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=i6tfWMiqn6tTusu+83OD8TRFhIHM3EtAwOkc3hLLH0g=; b=lgvjHRBc+NGbiSXlKjcU6KDefuv7CKcTEZvquN6nrZyKEzZk1UFrifpM4p9RzfrYYa 5O+q7l8I8r9R02+A1xTOo+BOnUbBxtkTjORndewEq2pdKJpjb8Lyaoz1isnB2xNO0OV4 t0aBNu1wj/V747S0EnTUcOjKNmobhwAhmyWfwTObyausCC1dJRm/FRkc7TdaRaoLo90F wowZu0u4W9Iz93gcky48S4Mjfk2hpTx8/30b919ivcuSkBz1QwY2FkyFDAs1eg9baStL uo1Anns2eOgyRtHC1Cjd34iNtHvM6htoFsT7KNDJyg96P1Zsl4MlgfDH8uow1yVVQN6S licw== X-Gm-Message-State: AOAM530qxHq4buHR5J3wplDLYORMZsLOjLqQeqlunhF6pS+GOeZBtcTz s2lH+d8xp0PpQoPsiVMk0Vxe6fQ+R5yXOl0sKPQ= X-Google-Smtp-Source: ABdhPJyOptnjgcBivEYhyOXQI3+huGmMZOpKV2bxRJc7Jd726yTpLneY9I2VH7UeyuCQbom7C2aTKuhNY1l2vzkQlf8= X-Received: by 2002:ac2:5b1a:: with SMTP id v26mr6672147lfn.534.1620189780883; Tue, 04 May 2021 21:43:00 -0700 (PDT) MIME-Version: 1.0 References: <20210430134754.179242-1-jolsa@kernel.org> In-Reply-To: From: Alexei Starovoitov Date: Tue, 4 May 2021 21:42:49 -0700 Message-ID: Subject: Re: [RFC] bpf: Fix crash on mm_init trampoline attachment To: Andrii Nakryiko Cc: Jiri Olsa , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Networking , bpf , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, May 4, 2021 at 5:36 PM Andrii Nakryiko wrote: > > On Tue, May 4, 2021 at 6:32 AM Jiri Olsa wrote: > > > > On Mon, May 03, 2021 at 03:45:28PM -0700, Andrii Nakryiko wrote: > > > On Fri, Apr 30, 2021 at 6:48 AM Jiri Olsa wrote: > > > > > > > > There are 2 mm_init functions in kernel. > > > > > > > > One in kernel/fork.c: > > > > static struct mm_struct *mm_init(struct mm_struct *mm, > > > > struct task_struct *p, > > > > struct user_namespace *user_ns) > > > > > > > > And another one in init/main.c: > > > > static void __init mm_init(void) > > > > > > > > The BTF data will get the first one, which is most likely > > > > (in my case) mm_init from init/main.c without arguments. did you hack pahole in some way to get to this point? I don't see this with pahole master. mm_init in BTF matches the one in init/main.c. The void one. Do you have two static mm_init-s in BTF somehow? In general it's possible to have different static funcs with the same name in kallsyms. I found 3 'seq_start' in my .config. So renaming static funcs is not an option. The simplest approach for now is to avoid emitting BTF if there is more than one func (that will prevent attaching because there won't be any BTF for that func). Long term I think BTF can store the .text offset and the verifier can avoid kallsym lookup. We do store insn_off in bpf_func_info for bpf progs. Something like this could be done for kernel and module funcs. But that's long term.