Message ID | cover.1683022164.git.geert+renesas@glider.be |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp500715vqo; Tue, 2 May 2023 03:29:54 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ57X1eHP6LY74jduoFEIywgC2N4jqnUr9JMxIp+UbYi+eYFstWVyMrWkXE8Gom5oQZNIxqd X-Received: by 2002:a05:6a00:b47:b0:63b:84a4:7b0 with SMTP id p7-20020a056a000b4700b0063b84a407b0mr21885281pfo.30.1683023394712; Tue, 02 May 2023 03:29:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683023394; cv=none; d=google.com; s=arc-20160816; b=gn94ahZm5lxNBeegRc0nwczEhv5SrxMze5lPlCsYPbvMWHUNKkqccBw2tQpxPdF6l1 H61efKJ+MrUGkvqzXWlQCsrmkbzpbg76EItQWSfmNvDP2PwxU8D/ANJWkPXtgGMRf/O1 5YaxFKK/x2Dvrmf9iDyuzsYQVcArFjOlPiqmqRLQyOLrNKfuVDZHJ0GhxY7xHuK5OofY iXYTHNYo/x4sbXzTd2rUxMYPUMmWlYDNuGFtyn784TCzizPdGC/yT2TrKfLqohcsx05I bvqfP9KIhp93V5njaKGoxYydoRHrdQORARirKqxWjcQ8wcM7QnwvwiiMtSHHcp26Rva2 FeQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=6UncpfgYEfLSyYaTksYn8se/MEGlKNTIJZC1RB9fxqw=; b=SmATdfrTN23BR/0DA3MxgmV+I0LjMlENSju5iVMWtcpYWBNovJn3CTStdTqCi607UF nYbWL/11cLC1W7eB/X5CZYRSRL3SJt8dMitN8mqTEDkhbAyoY0V4eUJqF3m1rwhf7+rz EqMABZACHEFyyYq3Pst3cAebyf9PmuyIdoFw3DYtPOFb66EPUeBlqb8Sf+E4HZsHBLl4 xqRP7neEgMRaHniT1r1kA9jCJ8aUKoux2ffepAbpwY2YZbGEtBsFcxjPY113s8DJH6g6 hwNqFLpbAY7Nl4puPlNe+EVHSgj5uLHpUu3s28Tbc0x5Xkp9y5s7FrXdDxovBc5xPp7m dLZw== ARC-Authentication-Results: i=1; mx.google.com; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k14-20020aa7998e000000b0063d27c285c9si30715908pfh.21.2023.05.02.03.29.40; Tue, 02 May 2023 03:29:54 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233774AbjEBKR1 (ORCPT <rfc822;rbbytesnap@gmail.com> + 99 others); Tue, 2 May 2023 06:17:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57070 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233373AbjEBKRS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 2 May 2023 06:17:18 -0400 Received: from baptiste.telenet-ops.be (baptiste.telenet-ops.be [IPv6:2a02:1800:120:4::f00:13]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4746830FD for <linux-kernel@vger.kernel.org>; Tue, 2 May 2023 03:17:12 -0700 (PDT) Received: from ramsan.of.borg ([IPv6:2a02:1810:ac12:ed30:f07a:92a2:297:162b]) by baptiste.telenet-ops.be with bizsmtp id rmHA290065FQxRj01mHA2s; Tue, 02 May 2023 12:17:10 +0200 Received: from rox.of.borg ([192.168.97.57]) by ramsan.of.borg with esmtp (Exim 4.95) (envelope-from <geert@linux-m68k.org>) id 1ptn4D-000ymU-UK; Tue, 02 May 2023 12:17:10 +0200 Received: from geert by rox.of.borg with local (Exim 4.95) (envelope-from <geert@linux-m68k.org>) id 1ptn4H-00AtQ3-Sh; Tue, 02 May 2023 12:17:09 +0200 From: Geert Uytterhoeven <geert+renesas@glider.be> To: Dmitry Torokhov <dmitry.torokhov@gmail.com>, Javier Martinez Canillas <javierm@redhat.com>, Brendan Higgins <brendan.higgins@linux.dev>, David Gow <davidgow@google.com> Cc: linux-input@vger.kernel.org, linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com, linux-kernel@vger.kernel.org, Geert Uytterhoeven <geert+renesas@glider.be> Subject: [PATCH 0/2] Input: tests - miscellaneous fixes Date: Tue, 2 May 2023 12:17:01 +0200 Message-Id: <cover.1683022164.git.geert+renesas@glider.be> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_LOW,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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764777939205552390?= X-GMAIL-MSGID: =?utf-8?q?1764777939205552390?= |
Series |
Input: tests - miscellaneous fixes
|
|
Message
Geert Uytterhoeven
May 2, 2023, 10:17 a.m. UTC
Hi all, This patch series fixes a crash in the new input selftest, and makes the test available when the KUnit framework is modular. Unfortunately test 3 still fails for me (tested on Koelsch (R-Car M2-W) and ARAnyM): KTAP version 1 # Subtest: input_core 1..3 input: Test input device as /devices/virtual/input/input1 ok 1 input_test_polling input: Test input device as /devices/virtual/input/input2 ok 2 input_test_timestamp input: Test input device as /devices/virtual/input/input3 # input_test_match_device_id: ASSERTION FAILED at # drivers/input/tests/input_test.c:99 Expected input_match_device_id(input_dev, &id) to be true, but is false not ok 3 input_test_match_device_id # input_core: pass:2 fail:1 skip:0 total:3 # Totals: pass:2 fail:1 skip:0 total:3 not ok 1 input_core Thanks! Geert Uytterhoeven (2): Input: tests - fix use-after-free and refcount underflow in input_test_exit() Input: tests - modular KUnit tests should not depend on KUNIT=y drivers/input/Kconfig | 2 +- drivers/input/tests/input_test.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
Comments
Hi Javier, On Tue, May 2, 2023 at 12:17 PM Geert Uytterhoeven <geert+renesas@glider.be> wrote: > This patch series fixes a crash in the new input selftest, and makes the > test available when the KUnit framework is modular. > > Unfortunately test 3 still fails for me (tested on Koelsch (R-Car M2-W) > and ARAnyM): > > KTAP version 1 > # Subtest: input_core > 1..3 > input: Test input device as /devices/virtual/input/input1 > ok 1 input_test_polling > input: Test input device as /devices/virtual/input/input2 > ok 2 input_test_timestamp > input: Test input device as /devices/virtual/input/input3 > # input_test_match_device_id: ASSERTION FAILED at # drivers/input/tests/input_test.c:99 > Expected input_match_device_id(input_dev, &id) to be true, but is false > not ok 3 input_test_match_device_id > # input_core: pass:2 fail:1 skip:0 total:3 > # Totals: pass:2 fail:1 skip:0 total:3 > not ok 1 input_core Adding more debug code shows that it's the test on evbit [1] in input_match_device_id() that fails. Looking at your input_test_match_device_id(), I think you expect the checks for the various bitmaps to be gated by "if (id->flags & INPUT_DEVICE_ID_MATCH_EVBIT)", like is done for the other checks? [1] https://elixir.bootlin.com/linux/latest/source/drivers/input/input.c#L1021 Gr{oetje,eeting}s, Geert
Geert Uytterhoeven <geert@linux-m68k.org> writes: Hello Geert, > Hi Javier, > > On Tue, May 2, 2023 at 12:17 PM Geert Uytterhoeven > <geert+renesas@glider.be> wrote: >> This patch series fixes a crash in the new input selftest, and makes the >> test available when the KUnit framework is modular. >> >> Unfortunately test 3 still fails for me (tested on Koelsch (R-Car M2-W) >> and ARAnyM): >> >> KTAP version 1 >> # Subtest: input_core >> 1..3 >> input: Test input device as /devices/virtual/input/input1 >> ok 1 input_test_polling >> input: Test input device as /devices/virtual/input/input2 >> ok 2 input_test_timestamp >> input: Test input device as /devices/virtual/input/input3 >> # input_test_match_device_id: ASSERTION FAILED at # drivers/input/tests/input_test.c:99 >> Expected input_match_device_id(input_dev, &id) to be true, but is false >> not ok 3 input_test_match_device_id >> # input_core: pass:2 fail:1 skip:0 total:3 >> # Totals: pass:2 fail:1 skip:0 total:3 >> not ok 1 input_core > > Adding more debug code shows that it's the test on evbit [1] in > input_match_device_id() that fails. > Looking at your input_test_match_device_id(), I think you expect > the checks for the various bitmaps to be gated by > "if (id->flags & INPUT_DEVICE_ID_MATCH_EVBIT)", like is done for the > other checks? > > [1] https://elixir.bootlin.com/linux/latest/source/drivers/input/input.c#L1021 > That's correct. In input_test_init(), the input dev is marked as capable of emitting EV_KEY BTN_LEFT and BTN_RIGHT. The goal of that test was to check this. That is, check if matches by the input dev capabilities in which case the __set_bit(EV_KEY, ...) would make the match true and __set_bit(EV_ABS, ..) would make the condition false. But maybe I misunderstood how the input_set_capability() and __set_bit() functions work ? I'll take a look to this tomorrow, thanks a lot for your report!
On Tue, May 02, 2023 at 06:31:51PM +0200, Javier Martinez Canillas wrote: > Geert Uytterhoeven <geert@linux-m68k.org> writes: > > Hello Geert, > > > Hi Javier, > > > > On Tue, May 2, 2023 at 12:17 PM Geert Uytterhoeven > > <geert+renesas@glider.be> wrote: > >> This patch series fixes a crash in the new input selftest, and makes the > >> test available when the KUnit framework is modular. > >> > >> Unfortunately test 3 still fails for me (tested on Koelsch (R-Car M2-W) > >> and ARAnyM): > >> > >> KTAP version 1 > >> # Subtest: input_core > >> 1..3 > >> input: Test input device as /devices/virtual/input/input1 > >> ok 1 input_test_polling > >> input: Test input device as /devices/virtual/input/input2 > >> ok 2 input_test_timestamp > >> input: Test input device as /devices/virtual/input/input3 > >> # input_test_match_device_id: ASSERTION FAILED at # drivers/input/tests/input_test.c:99 > >> Expected input_match_device_id(input_dev, &id) to be true, but is false > >> not ok 3 input_test_match_device_id > >> # input_core: pass:2 fail:1 skip:0 total:3 > >> # Totals: pass:2 fail:1 skip:0 total:3 > >> not ok 1 input_core > > > > Adding more debug code shows that it's the test on evbit [1] in > > input_match_device_id() that fails. > > Looking at your input_test_match_device_id(), I think you expect > > the checks for the various bitmaps to be gated by > > "if (id->flags & INPUT_DEVICE_ID_MATCH_EVBIT)", like is done for the > > other checks? > > > > [1] https://elixir.bootlin.com/linux/latest/source/drivers/input/input.c#L1021 > > > > That's correct. In input_test_init(), the input dev is marked as capable > of emitting EV_KEY BTN_LEFT and BTN_RIGHT. The goal of that test was to > check this. > > That is, check if matches by the input dev capabilities in which case the > __set_bit(EV_KEY, ...) would make the match true and __set_bit(EV_ABS, ..) > would make the condition false. > > But maybe I misunderstood how the input_set_capability() and __set_bit() > functions work ? > > I'll take a look to this tomorrow, thanks a lot for your report! Unfortunately (?) INPUT_DEVICE_ID_MATCH_*BIT have never had any effect, the kernel always used bitmaps when matching (with the assumption that if one does not care about given bitmap they can simply pass empty one), so I think what we need to change is: diff --git a/drivers/input/tests/input_test.c b/drivers/input/tests/input_test.c index 8b8ac3412a70..0540225f0288 100644 --- a/drivers/input/tests/input_test.c +++ b/drivers/input/tests/input_test.c @@ -87,7 +87,7 @@ static void input_test_timestamp(struct kunit *test) static void input_test_match_device_id(struct kunit *test) { struct input_dev *input_dev = test->priv; - struct input_device_id id; + struct input_device_id id = { 0 }; /* * Must match when the input device bus, vendor, product, version to avoid having garbage in the match data. I suppose we should remove INPUT_DEVICE_ID_MATCH_*BIT from mod_devicetable.h to avoid this confusion. Thanks.
Hi Dmitry, On Tue, May 2, 2023 at 7:05 PM Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > On Tue, May 02, 2023 at 06:31:51PM +0200, Javier Martinez Canillas wrote: > > Geert Uytterhoeven <geert@linux-m68k.org> writes: > > > On Tue, May 2, 2023 at 12:17 PM Geert Uytterhoeven > > > <geert+renesas@glider.be> wrote: > > >> This patch series fixes a crash in the new input selftest, and makes the > > >> test available when the KUnit framework is modular. > > >> > > >> Unfortunately test 3 still fails for me (tested on Koelsch (R-Car M2-W) > > >> and ARAnyM): > > >> > > >> KTAP version 1 > > >> # Subtest: input_core > > >> 1..3 > > >> input: Test input device as /devices/virtual/input/input1 > > >> ok 1 input_test_polling > > >> input: Test input device as /devices/virtual/input/input2 > > >> ok 2 input_test_timestamp > > >> input: Test input device as /devices/virtual/input/input3 > > >> # input_test_match_device_id: ASSERTION FAILED at # drivers/input/tests/input_test.c:99 > > >> Expected input_match_device_id(input_dev, &id) to be true, but is false > > >> not ok 3 input_test_match_device_id > > >> # input_core: pass:2 fail:1 skip:0 total:3 > > >> # Totals: pass:2 fail:1 skip:0 total:3 > > >> not ok 1 input_core > > > > > > Adding more debug code shows that it's the test on evbit [1] in > > > input_match_device_id() that fails. > > > Looking at your input_test_match_device_id(), I think you expect > > > the checks for the various bitmaps to be gated by > > > "if (id->flags & INPUT_DEVICE_ID_MATCH_EVBIT)", like is done for the > > > other checks? > > > > > > [1] https://elixir.bootlin.com/linux/latest/source/drivers/input/input.c#L1021 > > > > > > > That's correct. In input_test_init(), the input dev is marked as capable > > of emitting EV_KEY BTN_LEFT and BTN_RIGHT. The goal of that test was to > > check this. > > > > That is, check if matches by the input dev capabilities in which case the > > __set_bit(EV_KEY, ...) would make the match true and __set_bit(EV_ABS, ..) > > would make the condition false. > > > > But maybe I misunderstood how the input_set_capability() and __set_bit() > > functions work ? > > > > I'll take a look to this tomorrow, thanks a lot for your report! > > Unfortunately (?) INPUT_DEVICE_ID_MATCH_*BIT have never had any effect, > the kernel always used bitmaps when matching (with the assumption that > if one does not care about given bitmap they can simply pass empty one), > so I think what we need to change is: > > diff --git a/drivers/input/tests/input_test.c b/drivers/input/tests/input_test.c > index 8b8ac3412a70..0540225f0288 100644 > --- a/drivers/input/tests/input_test.c > +++ b/drivers/input/tests/input_test.c > @@ -87,7 +87,7 @@ static void input_test_timestamp(struct kunit *test) > static void input_test_match_device_id(struct kunit *test) > { > struct input_dev *input_dev = test->priv; > - struct input_device_id id; > + struct input_device_id id = { 0 }; > > /* > * Must match when the input device bus, vendor, product, version > > to avoid having garbage in the match data. Thanks, that did the trick! 3/3 tests pass. Gr{oetje,eeting}s, Geert
Geert Uytterhoeven <geert@linux-m68k.org> writes: > Hi Dmitry, > > On Tue, May 2, 2023 at 7:05 PM Dmitry Torokhov > <dmitry.torokhov@gmail.com> wrote: >> On Tue, May 02, 2023 at 06:31:51PM +0200, Javier Martinez Canillas wrote: >> > Geert Uytterhoeven <geert@linux-m68k.org> writes: >> > > On Tue, May 2, 2023 at 12:17 PM Geert Uytterhoeven >> > > <geert+renesas@glider.be> wrote: >> > >> This patch series fixes a crash in the new input selftest, and makes the >> > >> test available when the KUnit framework is modular. >> > >> >> > >> Unfortunately test 3 still fails for me (tested on Koelsch (R-Car M2-W) >> > >> and ARAnyM): >> > >> >> > >> KTAP version 1 >> > >> # Subtest: input_core >> > >> 1..3 >> > >> input: Test input device as /devices/virtual/input/input1 >> > >> ok 1 input_test_polling >> > >> input: Test input device as /devices/virtual/input/input2 >> > >> ok 2 input_test_timestamp >> > >> input: Test input device as /devices/virtual/input/input3 >> > >> # input_test_match_device_id: ASSERTION FAILED at # drivers/input/tests/input_test.c:99 >> > >> Expected input_match_device_id(input_dev, &id) to be true, but is false >> > >> not ok 3 input_test_match_device_id >> > >> # input_core: pass:2 fail:1 skip:0 total:3 >> > >> # Totals: pass:2 fail:1 skip:0 total:3 >> > >> not ok 1 input_core >> > > >> > > Adding more debug code shows that it's the test on evbit [1] in >> > > input_match_device_id() that fails. >> > > Looking at your input_test_match_device_id(), I think you expect >> > > the checks for the various bitmaps to be gated by >> > > "if (id->flags & INPUT_DEVICE_ID_MATCH_EVBIT)", like is done for the >> > > other checks? >> > > >> > > [1] https://elixir.bootlin.com/linux/latest/source/drivers/input/input.c#L1021 >> > > >> > >> > That's correct. In input_test_init(), the input dev is marked as capable >> > of emitting EV_KEY BTN_LEFT and BTN_RIGHT. The goal of that test was to >> > check this. >> > >> > That is, check if matches by the input dev capabilities in which case the >> > __set_bit(EV_KEY, ...) would make the match true and __set_bit(EV_ABS, ..) >> > would make the condition false. >> > >> > But maybe I misunderstood how the input_set_capability() and __set_bit() >> > functions work ? >> > >> > I'll take a look to this tomorrow, thanks a lot for your report! >> >> Unfortunately (?) INPUT_DEVICE_ID_MATCH_*BIT have never had any effect, >> the kernel always used bitmaps when matching (with the assumption that >> if one does not care about given bitmap they can simply pass empty one), >> so I think what we need to change is: >> >> diff --git a/drivers/input/tests/input_test.c b/drivers/input/tests/input_test.c >> index 8b8ac3412a70..0540225f0288 100644 >> --- a/drivers/input/tests/input_test.c >> +++ b/drivers/input/tests/input_test.c >> @@ -87,7 +87,7 @@ static void input_test_timestamp(struct kunit *test) >> static void input_test_match_device_id(struct kunit *test) >> { >> struct input_dev *input_dev = test->priv; >> - struct input_device_id id; >> + struct input_device_id id = { 0 }; >> >> /* >> * Must match when the input device bus, vendor, product, version >> >> to avoid having garbage in the match data. > > Thanks, that did the trick! 3/3 tests pass. > Oh, silly me. Are you going to post that as a proper patch ?