Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp790370iob; Wed, 18 May 2022 13:04:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwNa4Eeg2K8Nre8OLhvPTBlPtRtAdo11/EL1blIIiruJVGxCm7RUbRG/iLfuDqGcjdWtPeP X-Received: by 2002:a17:90b:4c4c:b0:1df:bab5:4f56 with SMTP id np12-20020a17090b4c4c00b001dfbab54f56mr1733095pjb.202.1652904282466; Wed, 18 May 2022 13:04:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652904282; cv=none; d=google.com; s=arc-20160816; b=yJKK5xzNb3c6GKQcLB2FzkN8pwoaAj6VoKmtMcCdNa+VeF4M3MxMYKo0E+3MSfL4Mg 4n9g9DWGYzIQH7xmy0fr13doadyER/LY9k1jELWhBhrmrrHq+I6/wIhOqsLcr+OGwknI 2Ec1yhtmoqupcyRY/gsYHrBtW5/yLjq9kzyIo4snWfpkI79OoY6moxNkBxgLh+fMEJbS AdQrnn67Y2+QjEaNeP7jMKm2+31nBVyHZ5KvoHe40ZXQzbzFt/5nPf0GXQoA2zg0cFkG re+qhc5DKPAP6RCjZ6o9Rt5PfOWYmKmpQggc8Y28r45qypqvHbSlFGl1FjtxqAD0nQ9v 3CbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=cg+jK1C7VyPf51yeEPplXxbPfgA1BVLN1iSf3puxwqE=; b=osd94BY8GIHC1YOMeE8uNeoxK3rC5MiXgvjuCT0vOkMqvOrWgWWIhW+bUEE0o8Uh46 UOJdOyE8E2xm3cpELKdP6TFdx6Rq3Xtzu3qxQI8joImxnCelUufWsMnV/0sj3WjdhXvb XjmBMqne5lVrMchKd5W2nY5c3Zt9tcsvVJouG7/PNXUDEVXV8fxu68Ca7/sjKJbOZ8f4 bvMQO6z9ZagrRRkMcQy34y19b3fe1+1c0ehexmswCcCv50rsp3UXFyix77H4U4Z5oiw/ WYBZJjdVe0coP0jXoBtDq+03aB6xQv6OkgOPa9McllaLvwIOkSireMKFx8VKkdGx2a7H nDGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HxFySj2l; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id p15-20020a17090a4f0f00b001dc6d247713si3632723pjh.70.2022.05.18.13.04.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 13:04:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HxFySj2l; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D13B21EE0BE; Wed, 18 May 2022 13:04:40 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242222AbiERUEe (ORCPT + 99 others); Wed, 18 May 2022 16:04:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242109AbiERUE3 (ORCPT ); Wed, 18 May 2022 16:04:29 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C2CCC1611DB for ; Wed, 18 May 2022 13:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1652904267; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cg+jK1C7VyPf51yeEPplXxbPfgA1BVLN1iSf3puxwqE=; b=HxFySj2lQYt4DE2Ay7fxS06X1/z7+wGiMdJ35ThNvjW02zESv11m9VvddpFEh/zOCnuueK pU4MMPsbwjYQAvjhzR//WmTOUNQk5g94JxiglEhE/2EcktDwQohef4cAXzTs1f75KdKGt/ xTYQ26ya3nwXNRQSS8pm6n2D/0f8HjA= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-455-VnHplXE5Pdytuyy6-DrgUg-1; Wed, 18 May 2022 16:04:24 -0400 X-MC-Unique: VnHplXE5Pdytuyy6-DrgUg-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 536B42800885; Wed, 18 May 2022 20:04:05 +0000 (UTC) Received: from asgard.redhat.com (unknown [10.36.110.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EDFB3492C14; Wed, 18 May 2022 20:04:01 +0000 (UTC) Date: Wed, 18 May 2022 22:03:58 +0200 From: Eugene Syromiatnikov To: Yonghong Song Cc: Jiri Olsa , Masami Hiramatsu , Steven Rostedt , Ingo Molnar , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , John Fastabend , KP Singh , netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH bpf v3 2/2] bpf_trace: bail out from bpf_kprobe_multi_link_attach when in compat Message-ID: <20220518200358.GB29226@asgard.redhat.com> References: <47cbdb76178a112763a3766a03d8cc51842fcab0.1652876188.git.esyr@redhat.com> <7bbb4a95-0d12-2a8f-9503-2613d774eaaa@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7bbb4a95-0d12-2a8f-9503-2613d774eaaa@fb.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 18, 2022 at 09:55:05AM -0700, Yonghong Song wrote: > > > On 5/18/22 5:22 AM, Eugene Syromiatnikov wrote: > >Since bpf_kprobe_multi_link_attach doesn't support 32-bit kernels > >for whatever reason, having it enabled for compat processes on 64-bit > >kernels makes even less sense due to discrepances in the type sizes > >that it does not handle. > > If I understand correctly, the reason is due to > in libbpf we have > struct bpf_link_create_opts { > size_t sz; /* size of this struct for forward/backward compatibility > */ > __u32 flags; > union bpf_iter_link_info *iter_info; > __u32 iter_info_len; > __u32 target_btf_id; > union { > struct { > __u64 bpf_cookie; > } perf_event; > struct { > __u32 flags; > __u32 cnt; > const char **syms; > const unsigned long *addrs; > const __u64 *cookies; > } kprobe_multi; > }; > size_t :0; > }; > > Note that we have `const unsigned long *addrs;` > > If we have 32-bit user space application and 64bit kernel, > and we will have userspace 32-bit pointers and kernel as > 64bit pointers and current kernel doesn't handle 32-bit > user pointer properly. > > Consider this may involve libbpf uapi change, maybe > we should change "const unsigned long *addrs;" to > "const __u64 *addrs;" considering we haven't freeze > libbpf UAPI yet. > > Otherwise, we stick to current code with this patch, > it will make it difficult to support 32-bit app with > 64-bit kernel for kprobe_multi in the future due to > uapi issues. > > WDYT? As 32 bit arches are "unsupported" currently, the change would be more a semantic one rather then practical; I don't mind having it here (basically, the tools/* part of [1]), though (assuming it is still possible to get it in 5.18). [1] https://lore.kernel.org/lkml/6ef675aeeea442fa8fc168cd1cb4e4e474f65a3f.1652772731.git.esyr@redhat.com/ > > > >Fixes: 0dcac272540613d4 ("bpf: Add multi kprobe link") > >Signed-off-by: Eugene Syromiatnikov > >--- > > kernel/trace/bpf_trace.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > >index 212faa4..2f83489 100644 > >--- a/kernel/trace/bpf_trace.c > >+++ b/kernel/trace/bpf_trace.c > >@@ -2412,7 +2412,7 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr > > int err; > > /* no support for 32bit archs yet */ > >- if (sizeof(u64) != sizeof(void *)) > >+ if (sizeof(u64) != sizeof(void *) || in_compat_syscall()) > > return -EOPNOTSUPP; > > if (prog->expected_attach_type != BPF_TRACE_KPROBE_MULTI) >