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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8C498C46467 for ; Tue, 29 Nov 2022 18:00:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233846AbiK2SAv (ORCPT ); Tue, 29 Nov 2022 13:00:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234427AbiK2SAs (ORCPT ); Tue, 29 Nov 2022 13:00:48 -0500 Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A24C26B38D for ; Tue, 29 Nov 2022 10:00:46 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id w37so8605031pga.5 for ; Tue, 29 Nov 2022 10:00:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TSI5hG4OpJqGbtaBgdMep1PH+0f8Fx62v+X9xZ1Fl94=; b=PVqG6QzEOT3S84aLFS3ebN/+dcswywiw+Tx6QqHnhwexLip1a+xdTIutTPQLHGODOE HUMJxl4i7tyn0wbyWEwmwvBAV5fXYIPCYh+PZ86ivuFF+Z2Evwdp8at1oPYfaqoo67JH DfFuCRaP2xlxa/ergCj0mErkRDRutP8j+PmWU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TSI5hG4OpJqGbtaBgdMep1PH+0f8Fx62v+X9xZ1Fl94=; b=PKThSOis/9LKaJh3B4H/rfpftOxB1Qx2Ln8XSsLpSxddl9uQKqTlgxZxZFuuNmnrdC xoShRSwS9KgbOYmJh7Lrdti84BAEtHNCqnPenVvKVOaPlhbbvFjoz2EaPrMEfM4aQ9IG 1B/GsE4L8izBB7Q9VmzirU0OHeRhcJderNS+DtTqOlyZN89IhQBWiSvAtc0Tg2HYOhIW BefQcUd9tDr+xjwAmsAX8Lo5K7uLa8zz/m+e7lQr5VZ0GgZEstrIIwvTLXJ/Xs9D4rbH Nrne80BJEj+w79OZ3WsXZiCXVchTeaQ7cPHIo7B8D261jvPaFWp2jAz17kaFrKPE8bxx mzAg== X-Gm-Message-State: ANoB5pn7qZtZMUiByCF3ibtl2QuLtB7u/IOSgLcvz8QnFQ48u0Xrgm8w Si285idsgcp1rUZ8QG+mSJZkqUz57OYerEbFXlP0Gy4OFQjSPyus X-Google-Smtp-Source: AA0mqf7u65cBqunX27gIoaEd70af4bgJCUl4C12pXRT79B5hou0hUEMAqHi1rrceJLd5hJK9hxM6ue6EB8yz9NAAWV8= X-Received: by 2002:a63:180a:0:b0:470:63e5:5c59 with SMTP id y10-20020a63180a000000b0047063e55c59mr32417999pgl.172.1669744846086; Tue, 29 Nov 2022 10:00:46 -0800 (PST) MIME-Version: 1.0 References: <20221103155756.687789-1-benjamin.tissoires@redhat.com> <20221103155756.687789-4-benjamin.tissoires@redhat.com> In-Reply-To: From: Florent Revest Date: Tue, 29 Nov 2022 19:00:35 +0100 Message-ID: Subject: Re: [PATCH hid v12 03/15] HID: initial BPF implementation To: Benjamin Tissoires Cc: Alexei Starovoitov , Mark Rutland , KP Singh , Jon Hunter , Greg KH , Jiri Kosina , Jonathan Corbet , Shuah Khan , Tero Kristo , LKML , "open list:HID CORE LAYER" , bpf , "open list:KERNEL SELFTEST FRAMEWORK" , "open list:DOCUMENTATION" , "linux-tegra@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 24, 2022 at 4:50 PM Benjamin Tissoires wrote: > > On Wed, Nov 23, 2022 at 9:14 PM Alexei Starovoitov > wrote: > > > > On Wed, Nov 23, 2022 at 6:53 AM Benjamin Tissoires > > wrote: > > > > > > Hi Jon, > > > > > > On Wed, Nov 23, 2022 at 2:25 PM Jon Hunter wrote: > > > > > > > > We have a kernel test that checks for new warning and error messages on > > > > boot and with this change I am now seeing the following error message on > > > > our Tegra platforms ... > > > > > > > > WARNING KERN hid_bpf: error while preloading HID BPF dispatcher: -13 > > > > > > > > I have a quick look at the code, but I can't say I am familiar with > > > > this. So I wanted to ask if a way to fix this or avoid this? I see the > > > > code returns 0, so one option would be to make this an informational or > > > > debug print. > > > > > > I am not in favor of debug in that case, because I suspect it'll hide > > > too much when getting a bug report. Informational could do, yes. > > > > > > However, before that, I'd like to dig a little bit more on why it is > > > failing. I thought arm64 now has support of tracing bpf programs, so I > > > would not expect this to fail. We have BPF trampolines on arm64 already but no ftrace direct calls right now. (so trampolines get jitted but don't get called eheh :)) So indeed BPF tracing programs (fentry/fexit/fmod_ret) do not work on arm64 at the moment. > > Unfortunately the patches to add support for such tracing bpf progs got stuck. > > Florent/Mark can probably share the latest status. We are working on an implementation of ftrace direct calls that would fit within the constraints of arm64 and play nice with the other users of the ftrace call site. Hopefully we have a patch to share in the next couple of weeks I'd say! > Oh... I noticed Jon's config was lacking CONFIG_FTRACE. So should I > also add a depends on CONFIG_FTRACE to enable HID-BPF? If HID-BPF fundamentally depends on a fmod_ret program being attached to function, it seems to me that it should depend on both: CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS (CONFIG_FTRACE or even CONFIG_DYNAMIC_FTRACE aren't enough, there can be architectures that do not support direct calls. here you noticed it on arm64 which luckily should get fixed someday soon but there could be other architectures with that issue too) and CONFIG_FUNCTION_ERROR_INJECTION (since [1] error injection needs to be explicitly opted-in, it's easy to miss it and fail to attach fmod_ret programs in mysterious ways) I'm thinking that maybe encoding these two dependencies in the CONFIG_HID_BPF is leaking too much of the bpf tracing abstraction to the user. Maybe the BPF Kconfig could provide "proxy" configs like HAVE_BPF_FENTRY_FEXIT, HAVE_BPF_FMOD_RET (naming is hard) to expose these dependencies better ? 1: https://lore.kernel.org/lkml/20221121104403.1545f9b5@gandalf.local.home/