Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Message-ID: <c4a8ca3c-c847-6930-db20-5de34ecd9437@intel.com>
Date:   Thu, 28 Sep 2023 10:09:58 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.15.1
Subject: Re: [PATCH v2 1/6] selftests/resctrl: Extend signal handler coverage
 to unmount on receiving signal
Content-Language: en-US
To:     =?UTF-8?Q?Ilpo_J=c3=a4rvinen?= <ilpo.jarvinen@linux.intel.com>
CC:     Shuah Khan <shuah@kernel.org>,
        Shuah Khan <skhan@linuxfoundation.org>,
        <linux-kselftest@vger.kernel.org>,
        =?UTF-8?Q?Maciej_Wiecz=c3=b3r-Retman?= 
        <maciej.wieczor-retman@intel.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>,
        <stable@vger.kernel.org>
References: <20230915154438.82931-1-ilpo.jarvinen@linux.intel.com>
 <20230915154438.82931-2-ilpo.jarvinen@linux.intel.com>
 <d2d94def-742d-7661-3632-b9f7e4996415@intel.com>
 <19f893e4-45e3-4e8f-c22-13241d5ff467@linux.intel.com>
From:   Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <19f893e4-45e3-4e8f-c22-13241d5ff467@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TFBtcnh5d2I5VVVQSUhIZHBReFNiTkdIZHJHdlI4SVplWXZiazJvaDJHaGNP?=
 =?utf-8?B?cmVJbXoyc1NmL3hjWUlxc3hXYWZlY3lVR3VLcnI2bGV3WlA2NmVtQ3V6bnJl?=
 =?utf-8?B?SkU3TFI4M1gwTlBSTGVBNytyVk5Ob292T0NLcWdUVHNBZzNRUVhkSXI0QzlF?=
 =?utf-8?B?MTZDWTVRT1g3VUdwdkV5YUFtY2FlcTNGeU1iRFQ1cXNMcTZaT1lEY2YrYmNY?=
 =?utf-8?B?RXNFR2kybTBmc3ozWFdaMUJSdStDbERkZVJsWll6QzBsU1k0Z05kNjJhanRo?=
 =?utf-8?B?VDlXRHdyOHgxa29WRlUvUi93OXUyREk5eWRick9mZ2ZOMFRRNkw1TGZ3RnFj?=
 =?utf-8?B?UHhnSFF4a0lKTTJwcUk3Z1UybjVsQzNqeGU2ZjgzVGdTRGI1T1g0TzE0aFJZ?=
 =?utf-8?B?NGZUNXBVRDNTdFozamtqUTJvR1pyN2pXZ3c1Z0UveGZJRUxiZFBwcGNEMmhN?=
 =?utf-8?B?RmZiMFg5emNnUlF0L1NkMUw0OTA3c0xjMHhpZmxUYXdFUHRjWm0rUjRFTW5T?=
 =?utf-8?B?UFJMK0J4YllMb09qS1pVcTM5QzFHSkQ5U2ZnSnVHcGx2djlmMW5RK1JMUHNK?=
 =?utf-8?B?L01rMEFPSy9MOHNLRVZ6bnJheE04ZjQ3MEJTejhqYWhoZmhHNlpHT3YwdmtD?=
 =?utf-8?B?YlY0aEc4NmY0Y1REQkJ5bHQ3KzI0cFovSVhFa3lDdjJIeUh3cXhFVnRoZjhp?=
 =?utf-8?B?Qlg1T244UEo1ZUU1b3R4RzFtWU1GdE52b1FWUlY2b3NPWE9ud0dFUG5kYTdp?=
 =?utf-8?B?VnAvZXJEVFBKMnplTUxhOEhvZ216YXg5Nm9YTWZOUTErbzRDL1FaSEJqeUY3?=
 =?utf-8?B?eXNPUGNtcjY2Mm4zRWJvMEErYzJLOW5sWTRYVk9FWE5zcXJvNzFxa0FZbUhk?=
 =?utf-8?B?TmEweDFmd01QWWhHNWVHeFdCQ2hyVDVFR3A5Rk1mQWNiZ1JHUXZucU5PTkFO?=
 =?utf-8?B?S0NEeU1WNWNMeVZLaVhJVXNMNU5IQXZPa0plOUFvOUkwUHd4ZmtBeG43UGwy?=
 =?utf-8?B?TmdYOWFubzN5OU9oVG5CQ1hQb1JoazA4cHhxTU9MUmdDVXU5b053WTUxVWxO?=
 =?utf-8?B?bDVmZE1aZTVoL3V1bzBJZGZqd29PMTZudEFaVWI5azZlMUZnV2w4SVUxR0dl?=
 =?utf-8?B?TmRlQVRyMDViYWc5ZEpWSkZqWlBLcjRwUkRiZ3Nib0owdEo4dHFudUFxcHNu?=
 =?utf-8?B?bnNYSW1ScHlUVWlnbE43MEU5WUpKanF3a3N4WUNsUWhvSVdORXJ3L3lkY1Fk?=
 =?utf-8?B?SWVnQUNvMXVWQ2dhaVY5bmxBcTg2UkxTUEQ2R3NwOEc1YkU3STljYzVPKzI1?=
 =?utf-8?B?S1ppVWVqNU1jeUtaeHRvWE5wY3FhMlFkS0V6aHFxV3EwcERiZDdzMUg5OFZw?=
 =?utf-8?B?bVNucEpDa2twdzBodDdSNDZBYzAyVlRyMm81akZYMGlTdW1aSkIrU3Z3N3J1?=
 =?utf-8?B?Z3U3UkNDQWRHUFNMdmZHaVEzc1BsTEJnL0FpOW9wUGovOGNMaWFLZEZGYWNH?=
 =?utf-8?B?TWFxSUJnUWt1dURRSC8xTDhsYjEzbk84Zk5meWdTQ1pOaExXaElsdlM2cWhW?=
 =?utf-8?B?aE1CWktMbWxVK3NvbTc3bGRwS2dqQ2daajlXSG4xMzQrMlJyQnFhRi9XTm9u?=
 =?utf-8?B?TFpZd3gvM1I4TGx4QjFrVk14SFltdWhlZXkwbE1IL3JjMnhvMUMvTjk1SlFv?=
 =?utf-8?B?eUZDQlBGZ1FlakVnVS82NXNqcENnbDNLWHdaR29pRlNEWFpGdzRTU3hqemsz?=
 =?utf-8?B?Z1p0cTlscUx2MFo1bVFZK2pCcFZTdm0zVEQrYXBMWDVXQkJEOXJjd3F0bm9T?=
 =?utf-8?B?blFJWVJnY0I3bGoyMXFveDNYRDd3Vm8zQkJnSEg5ek80ZHZIVit2Um1FK1Nm?=
 =?utf-8?B?UEFMeVNRc3dOdUNaQUFxRktacDEyUHFKU3dZdGtXMFcwbXNLQU9ZWm0vbCtn?=
 =?utf-8?B?OXRidDBEUnhRSW04eGVncjZnQU1rVlQwYTFPREg4L0pjSG4yRWFjWU1ONXlz?=
 =?utf-8?B?UTZ6aVdzKzhlTHRnYjFiRFJuRng0QVFUTXpjc1IrQ212OGpWNFhzaDIrRi96?=
 =?utf-8?B?cTNiSjlxVzFHNmJtbGJETzRsT1c2UTdkQ1FBMTc5eDVSMGJrakRrenFJdXYv?=
 =?utf-8?B?bWl1NW9IUnlzVy9MNW9sQWszbTVXRXhyZjVFZFNXVVZhb3A5VWphT1g0S1Rn?=
 =?utf-8?B?Q0E9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: e4727e90-0885-4e4e-ca28-08dbc045bfaf
X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2023 17:10:00.5786
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: q21RrTarfejVS/UQxyRcsSVVpqr5zuSe7i6aqXLgln8+/z7TFuF+g8+enYBfREJzgqP/mwBUZYiIrJ3vFg2gD+fEcKGahQLvvKt5kCBt2zs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR11MB6508
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Thu, 28 Sep 2023 10:11:04 -0700 (PDT)

Hi Ilpo,

On 9/28/2023 5:47 AM, Ilpo Järvinen wrote:
> On Tue, 26 Sep 2023, Reinette Chatre wrote:
>> On 9/15/2023 8:44 AM, Ilpo Järvinen wrote:

...

>>> +
>>> +static void run_mbm_test(const char * const *benchmark_cmd, int cpu_no)
>>> +{
>>> +	int res;
>>> +
>>> +	ksft_print_msg("Starting MBM BW change ...\n");
>>> +
>>> +	if (test_prepare())
>>> +		return;
>>>  
>>
>> I am not sure about this. With this exit the kselftest machinery is not
>> aware of the test passing or failing. I wonder if there should not rather
>> be a "goto" here that triggers ksft_test_result()?
> 
> Yes, ksft_test_result() is needed here (I forgot to add it).
> 
>> This needs some more 
>> thought though. First, with this change test_prepare() officially gains
>> responsibility to determine if a failure is transient (just a single test
>> fails) or permanent (no use trying any other tests if this fails). For
>> the former it would then be up to the caller to call ksft_test_result()
>> and for the latter test_prepare() will call ksft_exit_fail_msg().
> 
> Well, I didn't initially have test_prepare() at all but all this was 
> within the test functions (which will be consolidated to a single function 
> by the series that comes after the two series are done + one patch from 
> Maciej).
> 
> I was just trying to do what was done previously but it seems I forgot to 
> handle the result status on signal reg fail path.
> 
> TBH, I wouldn't mind if also the signal reg fail is just up'ed to 
> ksft_exit_fail_msg(). I don't think it can ever fail with the parameters 
> given to it so its error handling feels pretty much dead-code (unless some 
> crazy thing such as apparmor does something out of the blue, I don't know 
> if apparmor has capability override sigaction() but I've seen apparmor to
> create errors that from the surface make no sense whatsoever comparable
> to this case).
> 
> So basically this discussion is now about what to do with the mount 
> failing which already does _exit() before this patch (and possibly some
> hypotethical, new prepare code after the consolidation work which also
> will have some impact and I believe we might actually want to kill 
> test_prepare() at that point anyway).

Having failure during signal handler registration also trigger ksft_exit_fail_msg()
sounds fair to me. I am also ok with keeping the exit when mount fails.

If any future test_prepare() code does not imply a test exit then I hope it would
be obvious that ksft_test_result() needs to be called. Perhaps that can
be accomplished if test_prepare() does not exit the test but instead just
returns an error code (if needed it can use ksft_print_msg() internally for
any details about particular failures) and the caller call ksft_exit_fail_msg()
if test_prepare() fails? With the caller responsible for the ksft_exit_fail_msg()
as well as ksft_test_result() then any new addition may be guided to the
right calls. This considers hypothetical future changes to code that is
being consolidated so surely no strong opinions from my side.

>> Second, that SNC warning may be an inconvenience with a new goto. Here
>> it may be ok to print that message before the test failure?
> 
> I don't follow what you're referring to with "that SNC warning". To the 
> "Intel CMT may be inaccurate ..." one?

Yes, that is the warning. I envisioned addressing the issue by adding a
goto label right before the ksft_test_result() call within run_cmt_test()
in this case (but also in run_mbm_test()). Doing so would solve the issue
that test counters are incremented on test_prepare() failure but it will
also trigger the message you note and that would be confusing to the user if
the test failure was because of signal handler registration failure.

...

>>> diff --git a/tools/testing/selftests/resctrl/resctrl_val.c b/tools/testing/selftests/resctrl/resctrl_val.c
>>> index 51963a6f2186..a9fe61133119 100644
>>> --- a/tools/testing/selftests/resctrl/resctrl_val.c
>>> +++ b/tools/testing/selftests/resctrl/resctrl_val.c
>>> @@ -468,7 +468,9 @@ pid_t bm_pid, ppid;
>>>  
>>>  void ctrlc_handler(int signum, siginfo_t *info, void *ptr)
>>>  {
>>> -	kill(bm_pid, SIGKILL);
>>> +	/* Only kill child after bm_pid is set after fork() */
>>> +	if (bm_pid)
>>> +		kill(bm_pid, SIGKILL);
>>>  	umount_resctrlfs();
>>>  	tests_cleanup();
>>>  	ksft_print_msg("Ending\n\n");
>>> @@ -485,6 +487,8 @@ int signal_handler_register(void)
>>>  	struct sigaction sigact;
>>>  	int ret = 0;
>>>  
>>> +	bm_pid = 0;
>>> +
>>
>> Since this is an initialization fix in this area ... what
>> do you think of also initializing sigact? It could just be
>> a change to
>> 	struct sigaction sigact = {};
>>
>> This will prevent registering a signal handler with 
>> uninitialized sa_flags.
> 
> Nice catch. It seems quite bad bug, I'll add another patch to fix it.
> 
> Thanks once again for your reviews! I'll also address the changelog 
> improvements you mentioned against the other patches.
> 

Thanks to you for improving the resctrl selftests so significantly.
This work is very valuable because we use it to measure and gain
confidence in the health of the resctrl subsystem.

Reinette