Message ID | 20221101094341.3383073-5-tan.shaopeng@jp.fujitsu.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2857555wru; Tue, 1 Nov 2022 03:03:23 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4ZPnQ5XI2NMVHZ0BAOWei9Uyb0LsXAO7PReX7ZhoZtkLAazGKMQSO0Mhx0Rljgcdu4EUrx X-Received: by 2002:a17:90a:6286:b0:213:b01e:4290 with SMTP id d6-20020a17090a628600b00213b01e4290mr16859853pjj.42.1667297003399; Tue, 01 Nov 2022 03:03:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667297003; cv=none; d=google.com; s=arc-20160816; b=QpeIU9GkVIBFgrHAuRVQosN1vUWuRCBKt9kF3N8r1U6CYuB42ewnkCYkWjMxLcEmnI X+pNH93UNk787h1qS9WuiB8jAy6kXwVDvBm0VZiWpZfvX1+tLvaRJMxTa0s2oeKZbf/q qTjdneGjYAfQ7a9tUFk4hPVWd9ZVY+kgR0kcIIRdsJ/UAFPWGHo68o3xPRUOOTcAF9bg /ZozTUvDM5+6AhKo10p3iqfkCLcl1ufC/GQmBwau6mfDe76FdYlNRwjDoXPF939+lS2j 51UgsFirEYaVJ3tAbg1vqy8USnH5oetiJCy0TppPZmFM0PnpcjGDCti4uz09H9ESmbX2 gdmA== 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 :references:in-reply-to:message-id:date:subject:cc:to:from; bh=AshivuVckA6AgOgYrgkyipawQVAgb2gxnFxpsZDs6dw=; b=JMKdN3mbifNQj/smYGfM4SWpXBrRcwCU+3BT7wVqDLbyRdoCzMLuwNDuhWtsfKenNR jZG4fk6HaFGF5yrVB3ysd16WfAH9c2J37n6nlnVKP38QEZyaIGJqOtqar1dt6gs5muF1 9ecoFVIJWrUApJbpHHpEJdi0m9CT7ErVEDq6i2qXfFPhEn7Mclm88cymPZUANfADpdVp hfpJGYXm9HM3ceG725cqwgcx1uOqNUDBr3MwoilJM1T7TPhgivf5IPgQJrJc9UgagPwR 7Uvfxx1hNjHvJavBCGxvuXogMYhMgDdyRSK7lBH17LQoc1LQidWVSbf9qk6sEZ0pQbDI 2LNA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=fujitsu.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v3-20020a622f03000000b0056d8f42a69csi5110166pfv.145.2022.11.01.03.03.10; Tue, 01 Nov 2022 03:03:23 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=fujitsu.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230434AbiKAJtY (ORCPT <rfc822;kartikey406@gmail.com> + 99 others); Tue, 1 Nov 2022 05:49:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55590 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229907AbiKAJsx (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 1 Nov 2022 05:48:53 -0400 Received: from esa3.hc1455-7.c3s2.iphmx.com (esa3.hc1455-7.c3s2.iphmx.com [207.54.90.49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66F1A19026; Tue, 1 Nov 2022 02:48:52 -0700 (PDT) X-IronPort-AV: E=McAfee;i="6500,9779,10517"; a="94494670" X-IronPort-AV: E=Sophos;i="5.95,230,1661785200"; d="scan'208";a="94494670" Received: from unknown (HELO oym-r3.gw.nic.fujitsu.com) ([210.162.30.91]) by esa3.hc1455-7.c3s2.iphmx.com with ESMTP; 01 Nov 2022 18:48:50 +0900 Received: from oym-m4.gw.nic.fujitsu.com (oym-nat-oym-m4.gw.nic.fujitsu.com [192.168.87.61]) by oym-r3.gw.nic.fujitsu.com (Postfix) with ESMTP id 329E9CA1E2; Tue, 1 Nov 2022 18:48:49 +0900 (JST) Received: from oym-om4.fujitsu.com (oym-om4.o.css.fujitsu.com [10.85.58.164]) by oym-m4.gw.nic.fujitsu.com (Postfix) with ESMTP id 7CF99D55E3; Tue, 1 Nov 2022 18:48:48 +0900 (JST) Received: from cn-r05-10.example.com (n3235113.np.ts.nmh.cs.fujitsu.co.jp [10.123.235.113]) by oym-om4.fujitsu.com (Postfix) with ESMTP id 6491340164A60; Tue, 1 Nov 2022 18:48:48 +0900 (JST) From: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> To: Fenghua Yu <fenghua.yu@intel.com>, Reinette Chatre <reinette.chatre@intel.com>, Shuah Khan <shuah@kernel.org> Cc: linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, tan.shaopeng@jp.fujitsu.com Subject: [PATCH v3 4/5] selftests/resctrl: Cleanup properly when an error occurs in CAT test Date: Tue, 1 Nov 2022 18:43:40 +0900 Message-Id: <20221101094341.3383073-5-tan.shaopeng@jp.fujitsu.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20221101094341.3383073-1-tan.shaopeng@jp.fujitsu.com> References: <20221101094341.3383073-1-tan.shaopeng@jp.fujitsu.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS 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?1748287622713036654?= X-GMAIL-MSGID: =?utf-8?q?1748287622713036654?= |
Series |
Some improvements of resctrl selftest
|
|
Commit Message
Shaopeng Tan
Nov. 1, 2022, 9:43 a.m. UTC
After creating a child process with fork() in CAT test, if there is
an error occurs or such as a SIGINT signal is received, the parent
process will be terminated immediately, but the child process will not
be killed and also umount_resctrlfs() will not be called.
Add a signal handler like other tests to kill child process, umount
resctrlfs, cleanup result files, etc. when an error occurs.
Signed-off-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
---
tools/testing/selftests/resctrl/cat_test.c | 28 +++++++++++++++-------
1 file changed, 19 insertions(+), 9 deletions(-)
Comments
On 11/1/22 03:43, Shaopeng Tan wrote: > After creating a child process with fork() in CAT test, if there is > an error occurs or such as a SIGINT signal is received, the parent > process will be terminated immediately, but the child process will not > be killed and also umount_resctrlfs() will not be called. > > Add a signal handler like other tests to kill child process, umount > resctrlfs, cleanup result files, etc. when an error occurs. > > Signed-off-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> > --- > tools/testing/selftests/resctrl/cat_test.c | 28 +++++++++++++++------- > 1 file changed, 19 insertions(+), 9 deletions(-) > > diff --git a/tools/testing/selftests/resctrl/cat_test.c b/tools/testing/selftests/resctrl/cat_test.c > index 6a8306b0a109..5f81817f4366 100644 > --- a/tools/testing/selftests/resctrl/cat_test.c > +++ b/tools/testing/selftests/resctrl/cat_test.c > @@ -98,12 +98,21 @@ void cat_test_cleanup(void) > remove(RESULT_FILE_NAME2); > } > > +static void ctrl_handler(int signo) > +{ > + kill(bm_pid, SIGKILL); > + umount_resctrlfs(); > + tests_cleanup(); > + ksft_print_msg("Ending\n\n"); Is there a reason to print this message? Remove it unless it serves a purpose. > + > + exit(EXIT_SUCCESS); > +} > + > int cat_perf_miss_val(int cpu_no, int n, char *cache_type) > { > unsigned long l_mask, l_mask_1; > int ret, pipefd[2], sibling_cpu_no; > char pipe_message; > - pid_t bm_pid; Odd. bm_pid is used below - why remove it here? > > cache_size = 0; > > @@ -181,17 +190,19 @@ int cat_perf_miss_val(int cpu_no, int n, char *cache_type) > strcpy(param.filename, RESULT_FILE_NAME1); > param.num_of_runs = 0; > param.cpu_no = sibling_cpu_no; > + } else { > + /* set up ctrl-c handler */ > + if (signal(SIGINT, ctrl_handler) == SIG_ERR || > + signal(SIGHUP, ctrl_handler) == SIG_ERR || > + signal(SIGTERM, ctrl_handler) == SIG_ERR) > + printf("Failed to catch SIGNAL!\n"); Is perror() more appropriate here? > } > > remove(param.filename); > > ret = cat_val(¶m); > - if (ret) > - return ret; > - > - ret = check_results(¶m); > - if (ret) > - return ret; > + if (ret == 0) > + ret = check_results(¶m); Why not use a goto in error case to do umount_resctrlfs() instead of changing the conditionals? > > if (bm_pid == 0) { > /* Tell parent that child is ready */ > @@ -201,7 +212,6 @@ int cat_perf_miss_val(int cpu_no, int n, char *cache_type) > sizeof(pipe_message)) { > close(pipefd[1]); > perror("# failed signaling parent process"); > - return errno; > } > > close(pipefd[1]); > @@ -226,5 +236,5 @@ int cat_perf_miss_val(int cpu_no, int n, char *cache_type) > if (bm_pid) > umount_resctrlfs(); > > - return 0; > + return ret; > } With these changes made: Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> thanks, -- Shuah
Hi Shaopeng and Shuah, On 11/2/2022 2:41 AM, Shuah Khan wrote: > On 11/1/22 03:43, Shaopeng Tan wrote: >> After creating a child process with fork() in CAT test, if there is >> an error occurs or such as a SIGINT signal is received, the parent >> process will be terminated immediately, but the child process will not >> be killed and also umount_resctrlfs() will not be called. >> >> Add a signal handler like other tests to kill child process, umount >> resctrlfs, cleanup result files, etc. when an error occurs. >> >> Signed-off-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> >> --- >> tools/testing/selftests/resctrl/cat_test.c | 28 +++++++++++++++------- >> 1 file changed, 19 insertions(+), 9 deletions(-) >> >> diff --git a/tools/testing/selftests/resctrl/cat_test.c b/tools/testing/selftests/resctrl/cat_test.c >> index 6a8306b0a109..5f81817f4366 100644 >> --- a/tools/testing/selftests/resctrl/cat_test.c >> +++ b/tools/testing/selftests/resctrl/cat_test.c >> @@ -98,12 +98,21 @@ void cat_test_cleanup(void) >> remove(RESULT_FILE_NAME2); >> } >> +static void ctrl_handler(int signo) >> +{ >> + kill(bm_pid, SIGKILL); >> + umount_resctrlfs(); >> + tests_cleanup(); >> + ksft_print_msg("Ending\n\n"); > > Is there a reason to print this message? Remove it unless it serves > a purpose. This function appears to be a duplicate of existing resctrl_val.c:ctrlc_handler(). Could the duplication be avoided instead of refining the copy? > >> + >> + exit(EXIT_SUCCESS); >> +} >> + >> int cat_perf_miss_val(int cpu_no, int n, char *cache_type) >> { >> unsigned long l_mask, l_mask_1; >> int ret, pipefd[2], sibling_cpu_no; >> char pipe_message; >> - pid_t bm_pid; > > Odd. bm_pid is used below - why remove it here? There is a global bm_pid in resctrl_val.c that is made available via extern in resctrl.h. This is what causes this code to still compile but I would also like to learn why moving to that is desired as a change here. I expect such a big change to get a mention in the commit message. > >> cache_size = 0; >> @@ -181,17 +190,19 @@ int cat_perf_miss_val(int cpu_no, int n, char *cache_type) >> strcpy(param.filename, RESULT_FILE_NAME1); >> param.num_of_runs = 0; >> param.cpu_no = sibling_cpu_no; >> + } else { >> + /* set up ctrl-c handler */ >> + if (signal(SIGINT, ctrl_handler) == SIG_ERR || >> + signal(SIGHUP, ctrl_handler) == SIG_ERR || >> + signal(SIGTERM, ctrl_handler) == SIG_ERR) >> + printf("Failed to catch SIGNAL!\n"); > > Is perror() more appropriate here? Should we be using signal() at all? "man signal" reads: "WARNING: the behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead." "Failed to catch SIGNAL" also seems unclear to me. This is where a signal handler is set up, the signal for which the handler is installed has not arrived. > >> } >> remove(param.filename); >> ret = cat_val(¶m); >> - if (ret) >> - return ret; >> - >> - ret = check_results(¶m); >> - if (ret) >> - return ret; >> + if (ret == 0) >> + ret = check_results(¶m); > > Why not use a goto in error case to do umount_resctrlfs() instead of changing > the conditionals? My understanding is the code that follows is needed to synchronize the exits between the parent and child. It is the parent that will run umount_resctrlfs() and it should only do so after the child is done. A goto by the parent may thus cause umount_resctrlfs() to be run while the child still relies on it while a goto by the child may cause the parent not to receive the message that the child is complete. Reinette
Hi Shaopeng, On 11/1/2022 2:43 AM, Shaopeng Tan wrote: > After creating a child process with fork() in CAT test, if there is > an error occurs or such as a SIGINT signal is received, the parent I find the above hard to read. How about "..., if an error occurs or a signal such as SIGINT is received, ..." > process will be terminated immediately, but the child process will not > be killed and also umount_resctrlfs() will not be called. > > Add a signal handler like other tests to kill child process, umount > resctrlfs, cleanup result files, etc. when an error occurs. > > Signed-off-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> > --- > tools/testing/selftests/resctrl/cat_test.c | 28 +++++++++++++++------- > 1 file changed, 19 insertions(+), 9 deletions(-) > ... > @@ -201,7 +212,6 @@ int cat_perf_miss_val(int cpu_no, int n, char *cache_type) > sizeof(pipe_message)) { > close(pipefd[1]); > perror("# failed signaling parent process"); > - return errno; It looks like pipefd[1] will be closed twice if the write() failed. It does look strange to let the child continue to its infinite loop after the write() failed. I assume that it is because the parent will also be stuck and the new ctrl_handler() is expected to unblock both? Could you please add a comment to the code to clarify this flow? Thank you very much Reinette
Hi Reinette and Shuah, > On 11/2/2022 2:41 AM, Shuah Khan wrote: > > On 11/1/22 03:43, Shaopeng Tan wrote: > >> After creating a child process with fork() in CAT test, if there is > >> an error occurs or such as a SIGINT signal is received, the parent > >> process will be terminated immediately, but the child process will > >> not be killed and also umount_resctrlfs() will not be called. > >> > >> Add a signal handler like other tests to kill child process, umount > >> resctrlfs, cleanup result files, etc. when an error occurs. > >> > >> Signed-off-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> > >> --- > >> tools/testing/selftests/resctrl/cat_test.c | 28 > >> +++++++++++++++------- > >> 1 file changed, 19 insertions(+), 9 deletions(-) > >> > >> diff --git a/tools/testing/selftests/resctrl/cat_test.c > >> b/tools/testing/selftests/resctrl/cat_test.c > >> index 6a8306b0a109..5f81817f4366 100644 > >> --- a/tools/testing/selftests/resctrl/cat_test.c > >> +++ b/tools/testing/selftests/resctrl/cat_test.c > >> @@ -98,12 +98,21 @@ void cat_test_cleanup(void) > >> remove(RESULT_FILE_NAME2); > >> } > >> +static void ctrl_handler(int signo) > >> +{ > >> + kill(bm_pid, SIGKILL); > >> + umount_resctrlfs(); > >> + tests_cleanup(); > >> + ksft_print_msg("Ending\n\n"); > > > > Is there a reason to print this message? Remove it unless it serves a > > purpose. > > This function appears to be a duplicate of existing resctrl_val.c:ctrlc_handler(). > Could the duplication be avoided instead of refining the copy? Yes, it's a duplicate of existing resctrl_val.c:ctrlc_handler(). I will try to use resctrl_val.c:ctrlc_handler() in next version patch series. > >> + > >> + exit(EXIT_SUCCESS); > >> +} > >> + > >> int cat_perf_miss_val(int cpu_no, int n, char *cache_type) > >> { > >> unsigned long l_mask, l_mask_1; > >> int ret, pipefd[2], sibling_cpu_no; > >> char pipe_message; > >> - pid_t bm_pid; > > > > Odd. bm_pid is used below - why remove it here? > > There is a global bm_pid in resctrl_val.c that is made available via extern in > resctrl.h. This is what causes this code to still compile but I would also like to > learn why moving to that is desired as a change here. I expect such a big > change to get a mention in the commit message. Yes. I used global bm_pid, since bm_pid is used in ctrl_handler() before this function cat_perf_miss_val(). I will add a description to commit message. > >> cache_size = 0; > >> @@ -181,17 +190,19 @@ int cat_perf_miss_val(int cpu_no, int n, char > >> *cache_type) > >> strcpy(param.filename, RESULT_FILE_NAME1); > >> param.num_of_runs = 0; > >> param.cpu_no = sibling_cpu_no; > >> + } else { > >> + /* set up ctrl-c handler */ > >> + if (signal(SIGINT, ctrl_handler) == SIG_ERR || > >> + signal(SIGHUP, ctrl_handler) == SIG_ERR || > >> + signal(SIGTERM, ctrl_handler) == SIG_ERR) > >> + printf("Failed to catch SIGNAL!\n"); > > > > Is perror() more appropriate here? > > Should we be using signal() at all? "man signal" reads: > "WARNING: the behavior of signal() varies across UNIX versions, and has also > varied historically across different versions of Linux. > Avoid its use: use sigaction(2) instead." > > "Failed to catch SIGNAL" also seems unclear to me. This is where a signal > handler is set up, the signal for which the handler is installed has not arrived. I will use sigaction(2) and perror(). > >> } > >> remove(param.filename); > >> ret = cat_val(¶m); > >> - if (ret) > >> - return ret; > >> - > >> - ret = check_results(¶m); > >> - if (ret) > >> - return ret; > >> + if (ret == 0) > >> + ret = check_results(¶m); > > > > Why not use a goto in error case to do umount_resctrlfs() instead of > > changing the conditionals? > > My understanding is the code that follows is needed to synchronize the exits > between the parent and child. It is the parent that will run umount_resctrlfs() > and it should only do so after the child is done. A goto by the parent may thus > cause > umount_resctrlfs() to be run while the child still relies on it while a goto by the > child may cause the parent not to receive the message that the child is > complete. Yes, the code that follows is needed to synchronize the exits between the parent and child. > > @@ -201,7 +212,6 @@ int cat_perf_miss_val(int cpu_no, int n, char > *cache_type) > > sizeof(pipe_message)) { > > close(pipefd[1]); > > perror("# failed signaling parent process"); > > - return errno; > > It looks like pipefd[1] will be closed twice if the write() failed. This close(pipefd[1]); should also be removed. > It does look strange to let the child continue to its infinite loop after the write() > failed. I assume that it is because the parent will also be stuck and the new > ctrl_handler() is expected to unblock both? If a SIGNAL is received, ctrl_handler() will be called to kill the child process and exit parent process. If no SIGNAL is received, the parent process will kill the child process. (by else{kill(bm_pid, SIGKILL);}) > Could you please add a comment to the code to clarify this flow? I will add comments here. Best regards, Shaopeng Tan
diff --git a/tools/testing/selftests/resctrl/cat_test.c b/tools/testing/selftests/resctrl/cat_test.c index 6a8306b0a109..5f81817f4366 100644 --- a/tools/testing/selftests/resctrl/cat_test.c +++ b/tools/testing/selftests/resctrl/cat_test.c @@ -98,12 +98,21 @@ void cat_test_cleanup(void) remove(RESULT_FILE_NAME2); } +static void ctrl_handler(int signo) +{ + kill(bm_pid, SIGKILL); + umount_resctrlfs(); + tests_cleanup(); + ksft_print_msg("Ending\n\n"); + + exit(EXIT_SUCCESS); +} + int cat_perf_miss_val(int cpu_no, int n, char *cache_type) { unsigned long l_mask, l_mask_1; int ret, pipefd[2], sibling_cpu_no; char pipe_message; - pid_t bm_pid; cache_size = 0; @@ -181,17 +190,19 @@ int cat_perf_miss_val(int cpu_no, int n, char *cache_type) strcpy(param.filename, RESULT_FILE_NAME1); param.num_of_runs = 0; param.cpu_no = sibling_cpu_no; + } else { + /* set up ctrl-c handler */ + if (signal(SIGINT, ctrl_handler) == SIG_ERR || + signal(SIGHUP, ctrl_handler) == SIG_ERR || + signal(SIGTERM, ctrl_handler) == SIG_ERR) + printf("Failed to catch SIGNAL!\n"); } remove(param.filename); ret = cat_val(¶m); - if (ret) - return ret; - - ret = check_results(¶m); - if (ret) - return ret; + if (ret == 0) + ret = check_results(¶m); if (bm_pid == 0) { /* Tell parent that child is ready */ @@ -201,7 +212,6 @@ int cat_perf_miss_val(int cpu_no, int n, char *cache_type) sizeof(pipe_message)) { close(pipefd[1]); perror("# failed signaling parent process"); - return errno; } close(pipefd[1]); @@ -226,5 +236,5 @@ int cat_perf_miss_val(int cpu_no, int n, char *cache_type) if (bm_pid) umount_resctrlfs(); - return 0; + return ret; }