Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp701048pxp; Wed, 16 Mar 2022 14:52:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwYFlRfv3xIilIXRWIc8cZPQYWFWS8JmiXs07hWDKfOD0aB0ssQlCQOnN7xVK6+ibx2s9P7 X-Received: by 2002:a17:907:2d11:b0:6db:8eab:94dd with SMTP id gs17-20020a1709072d1100b006db8eab94ddmr1702068ejc.502.1647467560564; Wed, 16 Mar 2022 14:52:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647467560; cv=none; d=google.com; s=arc-20160816; b=KoNdFXgvWGilpL5kqtYyqSmeCBDmnvwniBvI+cZmz1AEAJ35jKevIekrlWIJ2J6nB8 d/gQ4+n4zZJKU+IHqUCktA8LKAt1tVpTIaTRjqQA7Ds74v89gpXAzKSkhljfnmO7fFg2 zjNGQqpfHPKU4aE1sJCdkcR5f1YCQIr/qaaFXeTAFvz3ZfZihyDbZLS7HDV7jlzsdEzt KJ1UVZIMfjkTrgOazAXG4h8sPwLwIaq8uDz2RYwQBWo6FhVJnKdxbd93e4wn6addHfD3 TqtpyYIGbFpHfdjGqJOCeX1OJ0UbwzYZFW+Wky/TpjtmQp7OTbExltNvMvfffXVOg5uv nvJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=4Jw/lpacLpo5DYktMebusJ8yB8R69yJCZ2uGaoaoQg0=; b=c0A5jVLiZQZrDkwGSGsiwBMwaGW3lUl7BYDeza6pkPatmqxMqTj9V9xxcVNm/H5g/t Qjruav3wg7np7FWv3w4x2biRPP6kQv3i2kl77Cnb1C56IfKKZYCM4GkujE6QiK/gv3nC MZiuP2rC1ndO4pjo/ULdzQcW15Te921xnQYJYI4WHzJPtdh3rx0l5K2qxED2y3/lCKNv LRAQi5kEFB2lipTRNXvF1cCjqPMpy6xGkBLrjwjmfDvNrZiMTd8FHhgzNvOeqysYjgBs hbgKwyXmscny339lrSdK8qcvdCV5yyDXx2iCds28Yxbuh7bnuNw/Q6zED1ac1VBm7L9O na3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UZK1KOBG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 5-20020a508e05000000b00418c2b5bda3si200812edw.133.2022.03.16.14.52.15; Wed, 16 Mar 2022 14:52:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UZK1KOBG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350400AbiCORE0 (ORCPT + 99 others); Tue, 15 Mar 2022 13:04:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55910 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350375AbiCOREZ (ORCPT ); Tue, 15 Mar 2022 13:04:25 -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 790B665F3 for ; Tue, 15 Mar 2022 10:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1647363792; 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=4Jw/lpacLpo5DYktMebusJ8yB8R69yJCZ2uGaoaoQg0=; b=UZK1KOBGwRCawHagelUQuW5bpSRIRbN4YeL0Ob/C0f2itCpU9IHZ104MbJKf39cmRwRH10 mVk8iMGDBlQplbBAQ2UDLf/XO1M7KsXUImsnFj/0f24Teb/xqhL+Nin+p5fRQvCL+c/87r 4HNnmdMXtKcWlnmB1ZHY9o4mRJOvMh8= Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-167-1I2mKmnaPeSmuz8txCBalQ-1; Tue, 15 Mar 2022 13:03:11 -0400 X-MC-Unique: 1I2mKmnaPeSmuz8txCBalQ-1 Received: by mail-pl1-f197.google.com with SMTP id e13-20020a17090301cd00b00150145346f9so8749184plh.23 for ; Tue, 15 Mar 2022 10:03:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Jw/lpacLpo5DYktMebusJ8yB8R69yJCZ2uGaoaoQg0=; b=MKccQnk2+nX484zJ+3Tf6803Pq5VSWTnGgqv5vWu/t3y2ich9rQ1j+mzf9c+y7tNVN b/jfMBLkFuqswavhv5DcEAkpgmdS+OuQjIh4B4QPo6bN/jdit6lXurf2xunqIDF8WDhF lCpvMToKvlgqKv3S0o2vz1WZGIuyFc6yH94Bw5sZGutMbKeTlLvKtI0DhYOofO2BgxLq /GuryeOv19wvXxB4z4QI8z5M13va8U4CkcpHTvvGlguWZ+6MSUvbRY+lpbBqVvyPkcKD JrcWJEs1asPS3S1SeP0t2+GC7xE82wPeL66D4Y/Uya2Z8KVb9NBk7vuAPhGbXCCk9T2O PpLg== X-Gm-Message-State: AOAM532leRYPtOLnue2zEQuRyvb9YOc+8l6+griB+NFhZFC8lVJ9a+4G 8aCdIYohoU7SA2qTJe29T0Aj4707SYNgNEU5/0dtYX+keQfFHfO1FGWtG45Qze7z6JaaQuPPEKk yrQ5lQs13kj1YFtKsH4xIkmdww1+w24kGMZeIJZkj X-Received: by 2002:a17:902:9308:b0:14e:def5:e6b5 with SMTP id bc8-20020a170902930800b0014edef5e6b5mr28994086plb.73.1647363788648; Tue, 15 Mar 2022 10:03:08 -0700 (PDT) X-Received: by 2002:a17:902:9308:b0:14e:def5:e6b5 with SMTP id bc8-20020a170902930800b0014edef5e6b5mr28994051plb.73.1647363788283; Tue, 15 Mar 2022 10:03:08 -0700 (PDT) MIME-Version: 1.0 References: <20220304172852.274126-1-benjamin.tissoires@redhat.com> <20220304172852.274126-15-benjamin.tissoires@redhat.com> In-Reply-To: From: Benjamin Tissoires Date: Tue, 15 Mar 2022 18:02:57 +0100 Message-ID: Subject: Re: [PATCH bpf-next v2 14/28] selftests/bpf: add tests for hid_{get|set}_data helpers To: Tero Kristo Cc: Greg KH , Jiri Kosina , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Shuah Khan , Dave Marchevsky , Joe Stringer , linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 Tue, Mar 15, 2022 at 5:51 PM Tero Kristo wrote: > > Hi Benjamin, > > On 04/03/2022 19:28, Benjamin Tissoires wrote: > > Simple test added here, with one use of each helper. > > > > Signed-off-by: Benjamin Tissoires > > > > --- > > > > changes in v2: > > - split the patch with libbpf left outside. > > --- > > tools/testing/selftests/bpf/prog_tests/hid.c | 65 ++++++++++++++++++++ > > tools/testing/selftests/bpf/progs/hid.c | 45 ++++++++++++++ > > 2 files changed, 110 insertions(+) > > > > diff --git a/tools/testing/selftests/bpf/prog_tests/hid.c b/tools/testing/selftests/bpf/prog_tests/hid.c > > index 91543b8078ca..74426523dd6f 100644 > > --- a/tools/testing/selftests/bpf/prog_tests/hid.c > > +++ b/tools/testing/selftests/bpf/prog_tests/hid.c > > @@ -297,6 +297,68 @@ static int test_hid_raw_event(struct hid *hid_skel, int uhid_fd, int sysfs_fd) > > return ret; > > } > > > > +/* > > + * Attach hid_set_get_data to the given uhid device, > > + * retrieve and open the matching hidraw node, > > + * inject one event in the uhid device, > > + * check that the program makes correct use of bpf_hid_{set|get}_data. > > + */ > > +static int test_hid_set_get_data(struct hid *hid_skel, int uhid_fd, int sysfs_fd) > > +{ > > + int err, hidraw_ino, hidraw_fd = -1; > > + char hidraw_path[64] = {0}; > > + u8 buf[10] = {0}; > > + int ret = -1; > > + > > + /* attach hid_set_get_data program */ > > + hid_skel->links.hid_set_get_data = > > + bpf_program__attach_hid(hid_skel->progs.hid_set_get_data, sysfs_fd); > > + if (!ASSERT_OK_PTR(hid_skel->links.hid_set_get_data, > > + "attach_hid(hid_set_get_data)")) > > + return PTR_ERR(hid_skel->links.hid_set_get_data); > > + > > + hidraw_ino = get_hidraw(hid_skel->links.hid_set_get_data); > > + if (!ASSERT_GE(hidraw_ino, 0, "get_hidraw")) > > + goto cleanup; > > + > > + /* open hidraw node to check the other side of the pipe */ > > + sprintf(hidraw_path, "/dev/hidraw%d", hidraw_ino); > > + hidraw_fd = open(hidraw_path, O_RDWR | O_NONBLOCK); > > + > > + if (!ASSERT_GE(hidraw_fd, 0, "open_hidraw")) > > + goto cleanup; > > + > > + /* inject one event */ > > + buf[0] = 1; > > + buf[1] = 42; > > + send_event(uhid_fd, buf, 6); > > + > > + /* read the data from hidraw */ > > + memset(buf, 0, sizeof(buf)); > > + err = read(hidraw_fd, buf, sizeof(buf)); > > + if (!ASSERT_EQ(err, 6, "read_hidraw")) > > + goto cleanup; > > + > > + if (!ASSERT_EQ(buf[2], (42 >> 2), "hid_set_get_data")) > > + goto cleanup; > > + > > + if (!ASSERT_EQ(buf[3], 1, "hid_set_get_data")) > > + goto cleanup; > > + > > + if (!ASSERT_EQ(buf[4], 42, "hid_set_get_data")) > > + goto cleanup; > > + > > + ret = 0; > > + > > +cleanup: > > + if (hidraw_fd >= 0) > > + close(hidraw_fd); > > + > > + hid__detach(hid_skel); > > + > > + return ret; > > +} > > + > > /* > > * Attach hid_rdesc_fixup to the given uhid device, > > * retrieve and open the matching hidraw node, > > @@ -395,6 +457,9 @@ void serial_test_hid_bpf(void) > > err = test_hid_raw_event(hid_skel, uhid_fd, sysfs_fd); > > ASSERT_OK(err, "hid"); > > > > + err = test_hid_set_get_data(hid_skel, uhid_fd, sysfs_fd); > > + ASSERT_OK(err, "hid_set_get_data"); > > + > > err = test_rdesc_fixup(hid_skel, uhid_fd, sysfs_fd); > > ASSERT_OK(err, "hid_rdesc_fixup"); > > > > diff --git a/tools/testing/selftests/bpf/progs/hid.c b/tools/testing/selftests/bpf/progs/hid.c > > index 2270448d0d3f..de6668471940 100644 > > --- a/tools/testing/selftests/bpf/progs/hid.c > > +++ b/tools/testing/selftests/bpf/progs/hid.c > > @@ -66,3 +66,48 @@ int hid_rdesc_fixup(struct hid_bpf_ctx *ctx) > > > > return 0; > > } > > + > > +SEC("hid/device_event") > > +int hid_set_get_data(struct hid_bpf_ctx *ctx) > > +{ > > + int ret; > > + __u8 *buf; > > + > > + buf = bpf_ringbuf_reserve(&ringbuf, 8, 0); > > Ordering of patches is probably wrong, it seems the ringbuf is defined > in patch #21 but used here. > > Also, this usage of ringbuf leads into running out of available memory > in the buffer if used for long time, it is not evident from the test > case written here but I spent a couple of hours debugging my own BPF > program that used ringbuf in similar way as what is done here. Basically > the producer idx is increased with the bpf_ringbuf_reserve / discard, > but the consumer index is not if you don't have a consumer in place. Oh, that's good to know. FWIW, on v3, we won't have to use a ringbuf at all. This is a new API break (sorry for that), but I think this will be better in the long run. I have chosen to use the hid_bpf_get_data() from [0]. The net advantage is that we get a pointer to the internal buffer that can be of any size, and we can even re-inject that same pointer into bpf_hid_raw_request() without having to use another buffer. I'm currently working on the documentation part and small fixes now that the big rewrite with that implementation is now done. Cheers, Benjamin > > I ended up using a global statically allocated buffer for the purpose > for now. > > -Tero > [0] https://lore.kernel.org/linux-input/CAO-hwJJqP5iivQZOu0LTYa1D5OuM_aVi=LH27Udc_VYkbFsrww@mail.gmail.com/