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 B48D2EB64DD for ; Wed, 2 Aug 2023 02:22:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230401AbjHBCWR (ORCPT ); Tue, 1 Aug 2023 22:22:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34016 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229557AbjHBCWQ (ORCPT ); Tue, 1 Aug 2023 22:22:16 -0400 Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 72845213E; Tue, 1 Aug 2023 19:22:15 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-2b9c907bc68so87264351fa.2; Tue, 01 Aug 2023 19:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690942933; x=1691547733; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tg1SPaJl42hfjSIHYNQoMyEABB2W7molrKSYX8RQGy0=; b=fvNXVl0pgOdLnojeelwiYSfJHuu6BPC0eENGlj1xmr20XORUOkzxvTPNlD0lXcCeoe 8DnDV91xWNIZKuTMjkBYiaaSj6OvcuudD1wxCeVPo50eDVJjDOVfWqlimmTxF4EwZBFn e9yDBi8yyi1jM3lHvXRFN2R4wPa20jSFbO5XR0oq5ulz4RtvFhPUPGCxv/0uhOjHddzV tEhXS0QXy5B0oOhExX15EKszy4txYxQuQs5BHI7s0y09auabnOW9+4vM3j8aZ+ZguSKk UnXnGtlBakb+gEXWYMYeUMI1EB0/EGPcCs2gNxAJTbsuYs0i64zsJK0d2lBaAlNTboob Wj6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690942933; x=1691547733; h=content-transfer-encoding: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=tg1SPaJl42hfjSIHYNQoMyEABB2W7molrKSYX8RQGy0=; b=iXrW+IZRrMQWh8z5SfdW3rlhUuSX/f9LNOZofLpleqbJ18t5hw9baqM298DtmSjL/Q Edn0FOvWDV8ePWwaCjw2oLzawgxXM7W/nZKZ26iNqzS4eEU70NV25zGVsfOY504305Ri fQKgFcncUlSaOvqcK2ugB+YldXONrP8fcxl4g5T0xM/tz1vsO5d9xU4EtmasJJaPhIml dk8ufvib7ANWXbyK/QQjxPFJKwKcF3rTJUvRJ702kteaMu2eVIoFkqiBMy3xELqvlHAX IJ/fq3gTE7rKhC59C6DhnPcqHufo2micPKAVlFr/Zq0FsjiJSvHsHvZe1vQ//KmD+d1D zkuQ== X-Gm-Message-State: ABy/qLbmf4booIJFuM1IqEX71xxOZ0ztc+yBlcEbxtrfPI0hE8Khk3IV laeS2o3bXuUmTbl+FrMSUTqK7ovXOavLJ703+ko= X-Google-Smtp-Source: APBJJlGoBvQLp+EM57aM03bT75dxdKy5hCV9qxCpnVKOhabfNLvU4n1NZ1cajNgcCMdejpRr9KSYVEToPM3UZfd8Dsw= X-Received: by 2002:a2e:b604:0:b0:2b9:b6e7:bd7 with SMTP id r4-20020a2eb604000000b002b9b6e70bd7mr4069527ljn.29.1690942933052; Tue, 01 Aug 2023 19:22:13 -0700 (PDT) MIME-Version: 1.0 References: <169078860386.173706.3091034523220945605.stgit@devnote2> <169078863449.173706.2322042687021909241.stgit@devnote2> <20230801085724.9bb07d2c82e5b6c6a6606848@kernel.org> <20230802000228.158f1bd605e497351611739e@kernel.org> <20230801112036.0d4ee60d@gandalf.local.home> <20230801113240.4e625020@gandalf.local.home> <20230801190920.7a1abfd5@gandalf.local.home> <20230802092146.9bda5e49528e6988ab97899c@kernel.org> <20230801204054.3884688e@rorschach.local.home> <20230801204407.7b284b00@rorschach.local.home> In-Reply-To: <20230801204407.7b284b00@rorschach.local.home> From: Alexei Starovoitov Date: Tue, 1 Aug 2023 19:22:01 -0700 Message-ID: Subject: Re: [PATCH v4 3/9] bpf/btf: Add a function to search a member of a struct/union To: Steven Rostedt Cc: "Masami Hiramatsu (Google)" , linux-trace-kernel@vger.kernel.org, LKML , Martin KaFai Lau , bpf , Sven Schnelle , Alexei Starovoitov , Jiri Olsa , Arnaldo Carvalho de Melo , Daniel Borkmann , Alan Maguire , Mark Rutland , Florent Revest , Peter Zijlstra , Thomas Gleixner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-trace-kernel@vger.kernel.org On Tue, Aug 1, 2023 at 5:44=E2=80=AFPM Steven Rostedt = wrote: > > On Tue, 1 Aug 2023 20:40:54 -0400 > Steven Rostedt wrote: > > > Maybe we can add a ftrace_partial_regs(fregs) that returns a > > partially filled pt_regs, and the caller that uses this obviously knows > > its partial (as it's in the name). But this doesn't quite help out arm6= 4 > > because unlike x86, struct ftrace_regs does not contain an address > > compatibility with pt_regs fields. It would need to do a copy. > > > > ftrace_partial_regs(fregs, ®s) ? > > Well, both would be pointers so you wouldn't need the "&", but it was > to stress that it would be copying one to the other. > > void ftrace_partial_regs(const struct ftrace_regs *fregs, struct pt_reg= s regs); Copy works, but why did you pick a different layout? Why not to use pt_regs ? if save of flags is slow, just skip that part and whatever else that is slow. You don't even need to zero out unsaved fields. Just ask the caller to zero out pt_regs before hand. Most users have per-cpu pt_regs that is being reused. So there will be one zero-out in the beginning and every partial save of regs will be fast. Then there won't be any need for copy-converter from ftrace_regs to pt_regs= . Maybe too much churn at this point. copy is fine.