Message ID | cover.1685443199.git.falcon@tinylab.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp2097813vqr; Tue, 30 May 2023 04:11:46 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5M5D2+vfUJ7GgrVcJSsFArndXkh+oLlQpp2ijpeTh2/PLXd2+z4+e2I+2hSPW/l+BaI49s X-Received: by 2002:a05:6a20:8e2a:b0:10a:cb95:5aa3 with SMTP id y42-20020a056a208e2a00b0010acb955aa3mr2417933pzj.7.1685445105769; Tue, 30 May 2023 04:11:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685445105; cv=none; d=google.com; s=arc-20160816; b=O+T2MN7akbMMRNmK82XwjMNYcwprX3rSfRZMyVKA1zWb/A8tsBd0g2GMrat0EHvpLF 2IRIL1Jx9tPlA80N5xkGrZstKXRWL0muFjKzBRsApRkkjcWivrRXcLhiHJzvYvr55WyC 0mWwIgCu4iAzfxz04yMLnKYkmngSDAe3YzQZsRwX+IBm2crsJyarMJbkydwB7yiCSFb1 MzvUmUGYoL/mhz5dyx0fc6we5xmdIX3PNge41hz3OUZS/P4Qx1JNRMZ5H6JZVN6jRcr4 Zus155/t76FJ5T5Q4C/DpUlyucTRJnFxZ7/B5EqbwHJSb25UKr/nQypZ4eUS6dN57yhd FkCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:feedback-id:content-transfer-encoding :mime-version:message-id:date:subject:cc:to:from; bh=fyzinr/PJJAPDZ+srGF5OAXwI8QB6Si+griabaxOT6w=; b=jsuGtPI0nqIIM3QCUnPo9BcC6tUDE+SZYyF4Z79aOtg3mo5pWDP89eyl9B9Ddc3luU HrGLjcjatiDYpm+camAMxIOaETs16ZxWpOrG8bT9jd97DQ8v3qclXl6KSwOIHAJQCTAn VMYHLnUU92UI1Hw33i33dIVSBNCKvnE3XA/X78iFxgl34QLl6FlJN9kxq8tNi9m4S9R/ I+28aub8UZc/uuUz+fiFdPLZTW9sUo5HAfkmFssE2/yj1rACM7KFp9IirJ2qfl5wAt4L kNJoI56qjKmVPnGQaNJ0X/jPyTynxG1baBCbVMaZx3nKuHHMYJ98jKjUikAnmTz6ONCN 9r8g== 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 q13-20020a63750d000000b0053f7fcd4705si4045330pgc.541.2023.05.30.04.11.31; Tue, 30 May 2023 04:11:45 -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 S231759AbjE3Ksg (ORCPT <rfc822;andrewvogler123@gmail.com> + 99 others); Tue, 30 May 2023 06:48:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231659AbjE3Kr5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 30 May 2023 06:47:57 -0400 Received: from bg4.exmail.qq.com (bg4.exmail.qq.com [43.155.67.158]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 910D8102; Tue, 30 May 2023 03:47:50 -0700 (PDT) X-QQ-mid: bizesmtp68t1685443664twnpak60 Received: from linux-lab-host.localdomain ( [119.123.130.226]) by bizesmtp.qq.com (ESMTP) with id ; Tue, 30 May 2023 18:47:43 +0800 (CST) X-QQ-SSF: 01200000000000D0V000000A0000000 X-QQ-FEAT: C46Rb8GPIEfLZaiD+Tj2Qw68S6CmHsgj7w+vsvgLRgBtK+77c1nm1Y+dZQciE yMI6X0Dlof9TqnGRL08Kb5tY/A2buyMdyGThpzwm1QqEHoKx4+PP5RZVSQGL6e09Ea2ij32 pPlQiDnGe+eyZW3rXAOllns96irDaF1DQpNSoiDmefKR8ZO5cCnENDJLPXotANFNbd81R+Y MiTH03hSIMCL7dPxdORkEpZqOKy7IzSF54yu/EZozLuPdDxiZXEZkCLD9UtK56W3I2zckfd HIY0mB8eeNxgNNPDkUCYIK9Awd6LZ1jompcNnI9riAwkgLIieRr3LCP0yt7i4pzAAoUxlcU 4jPq803VQxMD7rewyydupUZpW5wDtbxi7hA247/bsd/DPeXpc4lyUaSL+QCT5H2ADuk79yh X-QQ-GoodBg: 0 X-BIZMAIL-ID: 14120017678416040009 From: Zhangjin Wu <falcon@tinylab.org> To: w@1wt.eu Cc: falcon@tinylab.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-riscv@lists.infradead.org, thomas@t-8ch.de Subject: [PATCH 0/4] selftests/nolibc: add user-space 'efault' handler Date: Tue, 30 May 2023 18:47:38 +0800 Message-Id: <cover.1685443199.git.falcon@tinylab.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:tinylab.org:qybglogicsvrsz:qybglogicsvrsz3a-3 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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?1767317287307022392?= X-GMAIL-MSGID: =?utf-8?q?1767317287307022392?= |
Series |
selftests/nolibc: add user-space 'efault' handler
|
|
Message
Zhangjin Wu
May 30, 2023, 10:47 a.m. UTC
Hi, Willy, Thomas This is not really for merge, but only let it work as a demo code to test whether it is possible to restore the next test when there is a bad pointer access in user-space [1]. Besides, a new 'run' command is added to 'NOLIBC_TEST' environment variable or arguments to control the running iterations, this may be used to test the reentrancy issues, but no failures found currently ;-) With glibc, it works as following: $ ./nolibc-test run:2,syscall:28-30,stdlib:1 Running iteration(s): 2 Current iteration: 1 Running test 'syscall', from 28 to 30 28 dup3_m1 = -1 EBADF [OK] 29 efault_handler ! 11 SIGSEGV [OK] 30 execve_root = -1 EACCES [OK] Errors during this test: 0 Running test 'stdlib' 1 getenv_blah = <(null)> [OK] Errors during this test: 0 Total number of errors in the 1 iteration(s): 0 Current iteration: 2 Running test 'syscall' 28 dup3_m1 = -1 EBADF [OK] 29 efault_handler ! 11 SIGSEGV [OK] 30 execve_root = -1 EACCES [OK] Errors during this test: 0 Running test 'stdlib' 1 getenv_blah = <(null)> [OK] Errors during this test: 0 Total number of errors in the 2 iteration(s): 0 With nolibc, it will be skipped (run:2,syscall:28-30,stdlib:10): Running iteration(s): 2 Current iteration: 1 Running test 'syscall', from 28 to 30 28 dup3_m1 = -1 EBADF [OK] 29 efault_handler [SKIPPED] 30 execve_root = -1 EACCES [OK] Errors during this test: 0 Running test 'stdlib', from 10 to 10 10 strrchr_foobar_o = <obar> [OK] Errors during this test: 0 Total number of errors in the 1 iteration(s): 0 Current iteration: 2 Running test 'syscall', from 28 to 30 28 dup3_m1 = -1 EBADF [OK] 29 efault_handler [SKIPPED] 30 execve_root = -1 EACCES [OK] Errors during this test: 0 Running test 'stdlib', from 10 to 10 10 strrchr_foobar_o = <obar> [OK] Errors during this test: 0 Total number of errors in the 2 iteration(s): 0 Best regards, Zhangjin --- [1]: https://lore.kernel.org/linux-riscv/20230529113143.GB2762@1wt.eu/ Zhangjin Wu (4): selftests/nolibc: allow rerun with the same settings selftests/nolibc: add rerun support selftests/nolibc: add user space efault handler selftests/nolibc: add user-space efault restore test case tools/testing/selftests/nolibc/nolibc-test.c | 247 +++++++++++++++++-- 1 file changed, 221 insertions(+), 26 deletions(-)
Comments
Hi Zhangjin, On Tue, May 30, 2023 at 06:47:38PM +0800, Zhangjin Wu wrote: > Hi, Willy, Thomas > > This is not really for merge, but only let it work as a demo code to > test whether it is possible to restore the next test when there is a bad > pointer access in user-space [1]. > > Besides, a new 'run' command is added to 'NOLIBC_TEST' environment > variable or arguments to control the running iterations, this may be > used to test the reentrancy issues, but no failures found currently ;-) Since the tests we're running are essentially API tests, I'm having a hard time seeing in which case it can be useful to repeat the tests. I'm not necessarily against doing it, I'm used to repeating tests for example in anything sensitive to timing or race conditions, it's just that here I'm not seeing the benefit. And the fact you found no failure is rather satisfying because the opposite would have surprised me. Regarding the efault handler, I don't think it's a good idea until we have signal+longjmp support in nolibc. Because running different tests with different libcs kind of defeats the purpose of the test in the first place. The reason why I wanted nolibc-test to be portable to at least one other libc is to help the developer figure if a failure is in the nolibc syscall they're implementing or in the test itself. Here if we start to say that some parts cannot be tested similarly, the benefit disappears. I mentioned previously that I'm not particularly impatient to work on signals and longjmp. But in parallel I understand how this can make the life of some developers easier and even allow to widen the spectrum of some tests. Thus, maybe in the end it could be beneficial to make progress on this front and support these. We should make sure that this doesn't inflate the code base however. I guess I'd be fine with ignoring libc- based restarts on EINTR, alt stacks and so on and keeping this minimal (i.e. catch a segfault/bus error/sigill in a test program, or a Ctrl-C in a tiny shell). Just let us know if you think that's something you could be interested in exploring. There might be differences between architectures, I have not checked. Thanks, Willy
On 2023-06-04 13:05:18+0200, Willy Tarreau wrote: > Hi Zhangjin, > > On Tue, May 30, 2023 at 06:47:38PM +0800, Zhangjin Wu wrote: > > Hi, Willy, Thomas > > > > This is not really for merge, but only let it work as a demo code to > > test whether it is possible to restore the next test when there is a bad > > pointer access in user-space [1]. > > > > Besides, a new 'run' command is added to 'NOLIBC_TEST' environment > > variable or arguments to control the running iterations, this may be > > used to test the reentrancy issues, but no failures found currently ;-) > > Since the tests we're running are essentially API tests, I'm having > a hard time seeing in which case it can be useful to repeat the tests. > I'm not necessarily against doing it, I'm used to repeating tests for > example in anything sensitive to timing or race conditions, it's just > that here I'm not seeing the benefit. And the fact you found no failure > is rather satisfying because the opposite would have surprised me. > > Regarding the efault handler, I don't think it's a good idea until we > have signal+longjmp support in nolibc. Because running different tests > with different libcs kind of defeats the purpose of the test in the > first place. The reason why I wanted nolibc-test to be portable to at > least one other libc is to help the developer figure if a failure is in > the nolibc syscall they're implementing or in the test itself. Here if > we start to say that some parts cannot be tested similarly, the benefit > disappears. > > I mentioned previously that I'm not particularly impatient to work on > signals and longjmp. But in parallel I understand how this can make the > life of some developers easier and even allow to widen the spectrum of > some tests. Thus, maybe in the end it could be beneficial to make progress > on this front and support these. We should make sure that this doesn't > inflate the code base however. I guess I'd be fine with ignoring libc- > based restarts on EINTR, alt stacks and so on and keeping this minimal > (i.e. catch a segfault/bus error/sigill in a test program, or a Ctrl-C > in a tiny shell). > > Just let us know if you think that's something you could be interested > in exploring. There might be differences between architectures, I have > not checked. If the goal is to handle hard errors like segfaults more gracefully, would it not be easier to run each testcase in a subprocess? Then we can just check if the child exited successfully. It should also be completely architecture agnostic. Thomas
On Sun, Jun 04, 2023 at 09:07:25PM +0200, Thomas Weißschuh wrote: > On 2023-06-04 13:05:18+0200, Willy Tarreau wrote: > > Hi Zhangjin, > > > > On Tue, May 30, 2023 at 06:47:38PM +0800, Zhangjin Wu wrote: > > > Hi, Willy, Thomas > > > > > > This is not really for merge, but only let it work as a demo code to > > > test whether it is possible to restore the next test when there is a bad > > > pointer access in user-space [1]. > > > > > > Besides, a new 'run' command is added to 'NOLIBC_TEST' environment > > > variable or arguments to control the running iterations, this may be > > > used to test the reentrancy issues, but no failures found currently ;-) > > > > Since the tests we're running are essentially API tests, I'm having > > a hard time seeing in which case it can be useful to repeat the tests. > > I'm not necessarily against doing it, I'm used to repeating tests for > > example in anything sensitive to timing or race conditions, it's just > > that here I'm not seeing the benefit. And the fact you found no failure > > is rather satisfying because the opposite would have surprised me. > > > > Regarding the efault handler, I don't think it's a good idea until we > > have signal+longjmp support in nolibc. Because running different tests > > with different libcs kind of defeats the purpose of the test in the > > first place. The reason why I wanted nolibc-test to be portable to at > > least one other libc is to help the developer figure if a failure is in > > the nolibc syscall they're implementing or in the test itself. Here if > > we start to say that some parts cannot be tested similarly, the benefit > > disappears. > > > > I mentioned previously that I'm not particularly impatient to work on > > signals and longjmp. But in parallel I understand how this can make the > > life of some developers easier and even allow to widen the spectrum of > > some tests. Thus, maybe in the end it could be beneficial to make progress > > on this front and support these. We should make sure that this doesn't > > inflate the code base however. I guess I'd be fine with ignoring libc- > > based restarts on EINTR, alt stacks and so on and keeping this minimal > > (i.e. catch a segfault/bus error/sigill in a test program, or a Ctrl-C > > in a tiny shell). > > > > Just let us know if you think that's something you could be interested > > in exploring. There might be differences between architectures, I have > > not checked. > > If the goal is to handle hard errors like segfaults more gracefully, > would it not be easier to run each testcase in a subprocess? > > Then we can just check if the child exited successfully. > > It should also be completely architecture agnostic. Could be, indeed. However it would complexify a bit strace debugging, but yeah that might be something to think about. Willy
> On 2023-06-04 13:05:18+0200, Willy Tarreau wrote: > > Hi Zhangjin, > > > > On Tue, May 30, 2023 at 06:47:38PM +0800, Zhangjin Wu wrote: > > > Hi, Willy, Thomas > > > > > > > Just let us know if you think that's something you could be interested > > in exploring. There might be differences between architectures, I have > > not checked. > > If the goal is to handle hard errors like segfaults more gracefully, > would it not be easier to run each testcase in a subprocess? > > Then we can just check if the child exited successfully. > Yeah, it is easier, it may be possible to simply pass the test case to something like test_fork() and let the child to run it there. I will take a try, thanks very much. > It should also be completely architecture agnostic. It is for we can reuse the test_fork() stuff. Best regards, Zhangjin > > Thomas