From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7F85EB64DA for ; Tue, 18 Jul 2023 11:24:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231650AbjGRLYZ (ORCPT ); Tue, 18 Jul 2023 07:24:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40290 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229953AbjGRLYW (ORCPT ); Tue, 18 Jul 2023 07:24:22 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB36AE8 for ; Tue, 18 Jul 2023 04:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1689679420; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=E25e9dvQIenP2167tOlvP3NdJMvW6/ZDuSZb/NoTrxg=; b=bM/TNRGC6ZNF+H/NKLH7/qBFAomXtYtgN0I9hc8S2oBq+t+SuOgSG04wBv7uUnqpjthJFs 9Jl2yoFn2JauAK98psAOstJpM0ijCOxtTeCclwK6GMD+fiXAQ0zMFjrALYtJ9c95G2PuRq aYIXVeJ3/Kh206Hy6S7AXIHS0JddYvE= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-636-Up15ckMIOw2oIbxKX9HNkQ-1; Tue, 18 Jul 2023 07:23:39 -0400 X-MC-Unique: Up15ckMIOw2oIbxKX9HNkQ-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-3faabd8fd33so29798455e9.0 for ; Tue, 18 Jul 2023 04:23:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689679418; x=1692271418; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=E25e9dvQIenP2167tOlvP3NdJMvW6/ZDuSZb/NoTrxg=; b=Cv/jqhPPsqp4i7QU8OOBmoxZe+kIv47juTillvdok7l7KDIFphSPHfDMg1WNqtO7Vl WEm0Cc8JDi0L5VuV5M8i5n6E7YCMjitzTziNPaV0qg16kXeRbUp47wnc1YlcuZ8zVTiu EAwJSvg/F5dhjYciEk3f0iFCdHr6YwmNw2G0bHc/a00GtXjhYMSK4a1CpH24z6m2LNZN 64eIkd+yYg5gAlxLnS63/tFvYBp7UtaqZNHHrNkRVDFMEC0/9hLkTDhJVCT0xJMhoD5l 1kSlMpBBT8kwHbw6f/GudKRJvH7mxno4sOU94dUsymdfdtEff1vcIfCUhHZcem2DOmys Cumg== X-Gm-Message-State: ABy/qLbH2HROooWzOAy66UfhdrV+JK/TVdB6E4r7n17O92QU65YsgyWN d5vCaaawlulKYK3O9WKRmHHbVUxuj4OL+focul6IlX/n1hR/1kuV5Wkp4DApy6EEZ7oVuofPCr5 lD6DtM4a12EGqGhrD2VaLS3U7 X-Received: by 2002:a1c:750a:0:b0:3fb:f926:4937 with SMTP id o10-20020a1c750a000000b003fbf9264937mr1554396wmc.31.1689679417732; Tue, 18 Jul 2023 04:23:37 -0700 (PDT) X-Google-Smtp-Source: APBJJlHcfZuXNRThSAK3VX4YePcYyb17v2vQFJ2pWXoCB5RExjoYRAh4jCIM+f39eOI/dJI2PCAPGg== X-Received: by 2002:a1c:750a:0:b0:3fb:f926:4937 with SMTP id o10-20020a1c750a000000b003fbf9264937mr1554376wmc.31.1689679417344; Tue, 18 Jul 2023 04:23:37 -0700 (PDT) Received: from ?IPV6:2003:cb:c740:6200:84e1:eabc:8e2:7429? (p200300cbc740620084e1eabc08e27429.dip0.t-ipconnect.de. [2003:cb:c740:6200:84e1:eabc:8e2:7429]) by smtp.gmail.com with ESMTPSA id o18-20020a05600c379200b003fa973e6612sm9994481wmr.44.2023.07.18.04.23.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Jul 2023 04:23:36 -0700 (PDT) Message-ID: <1314fe0e-dd32-bf10-0a33-2b571dad70bd@redhat.com> Date: Tue, 18 Jul 2023 13:23:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Content-Language: en-US To: Ryan Roberts , Andrew Morton , Shuah Khan , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Mark Brown , John Hubbard , Florent Revest , Peter Xu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org References: <20230717103152.202078-1-ryan.roberts@arm.com> <20230717103152.202078-7-ryan.roberts@arm.com> <20501a7c-19f6-4154-aebc-49df04c9b043@redhat.com> <2e5baba4-c8ef-9da4-a2d6-3cf383ed05bd@arm.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v2 6/8] selftests/mm: Make migration test robust to failure In-Reply-To: <2e5baba4-c8ef-9da4-a2d6-3cf383ed05bd@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18.07.23 12:49, Ryan Roberts wrote: > On 17/07/2023 18:40, David Hildenbrand wrote: >> On 17.07.23 12:31, Ryan Roberts wrote: >>> The `migration` test currently has a number of robustness problems that >>> cause it to hang and leak resources. >>> >>> Timeout: There are 3 tests, which each previously ran for 60 seconds. >>> However, the timeout in mm/settings for a single test binary was set to >>> 45 seconds. So when run using run_kselftest.sh, the top level timeout >>> would trigger before the test binary was finished. Solve this by meeting >>> in the middle; each of the 3 tests now runs for 20 seconds (for a total >>> of 60), and the top level timeout is set to 90 seconds. >>> >>> Leaking child processes: the `shared_anon` test fork()s some children >>> but then an ASSERT() fires before the test kills those children. The >>> assert causes immediate exit of the parent and leaking of the children. >>> Furthermore, if run using the run_kselftest.sh wrapper, the wrapper >>> would get stuck waiting for those children to exit, which never happens. >>> Solve this by deferring any asserts until after the children are killed. >>> The same pattern is used for the threaded tests for uniformity. >>> >>> With these changes, the test binary now runs to completion on arm64, >>> with 2 tests passing and the `shared_anon` test failing. >>> >>> Signed-off-by: Ryan Roberts >>> --- >>>   tools/testing/selftests/mm/migration.c | 14 ++++++++++---- >>>   tools/testing/selftests/mm/settings    |  2 +- >>>   2 files changed, 11 insertions(+), 5 deletions(-) >>> >>> diff --git a/tools/testing/selftests/mm/migration.c >>> b/tools/testing/selftests/mm/migration.c >>> index 379581567f27..189d7d9070e8 100644 >>> --- a/tools/testing/selftests/mm/migration.c >>> +++ b/tools/testing/selftests/mm/migration.c >>> @@ -15,7 +15,7 @@ >>>   #include >>>     #define TWOMEG (2<<20) >>> -#define RUNTIME (60) >>> +#define RUNTIME (20) >>>     #define ALIGN(x, a) (((x) + (a - 1)) & (~((a) - 1))) >>>   @@ -118,6 +118,7 @@ TEST_F_TIMEOUT(migration, private_anon, 2*RUNTIME) >>>   { >>>       uint64_t *ptr; >>>       int i; >>> +    int ret; >>>         if (self->nthreads < 2 || self->n1 < 0 || self->n2 < 0) >>>           SKIP(return, "Not enough threads or NUMA nodes available"); >>> @@ -131,9 +132,10 @@ TEST_F_TIMEOUT(migration, private_anon, 2*RUNTIME) >>>           if (pthread_create(&self->threads[i], NULL, access_mem, ptr)) >>>               perror("Couldn't create thread"); >>>   -    ASSERT_EQ(migrate(ptr, self->n1, self->n2), 0); >>> +    ret = migrate(ptr, self->n1, self->n2); >>>       for (i = 0; i < self->nthreads - 1; i++) >>>           ASSERT_EQ(pthread_cancel(self->threads[i]), 0); >>> +    ASSERT_EQ(ret, 0); >> >> Why is that required? This does not involve fork. > > It's not required. I was just trying to keep everything aligned to the same pattern. > >> >>>   } >>>     /* >>> @@ -144,6 +146,7 @@ TEST_F_TIMEOUT(migration, shared_anon, 2*RUNTIME) >>>       pid_t pid; >>>       uint64_t *ptr; >>>       int i; >>> +    int ret; >>>         if (self->nthreads < 2 || self->n1 < 0 || self->n2 < 0) >>>           SKIP(return, "Not enough threads or NUMA nodes available"); >>> @@ -161,9 +164,10 @@ TEST_F_TIMEOUT(migration, shared_anon, 2*RUNTIME) >>>               self->pids[i] = pid; >>>       } >>>   -    ASSERT_EQ(migrate(ptr, self->n1, self->n2), 0); >>> +    ret = migrate(ptr, self->n1, self->n2); >>>       for (i = 0; i < self->nthreads - 1; i++) >>>           ASSERT_EQ(kill(self->pids[i], SIGTERM), 0); >>> +    ASSERT_EQ(ret, 0); >> >> >> Might be cleaner to also: > > Or instead of? I agree this is neater, so will undo the moving of the ASSERT() > and rely on this prctl. I was thinking about possible races when our parent process already quits before our child managed to set the prctl. prctl() won't do anything in that case, hmmmm. But similarly, existing code might already trigger the migrate() + kill before the child processes even started to access_mem(). Racy :) -- Cheers, David / dhildenb