From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 831A93858D32 for ; Mon, 29 Aug 2022 14:02:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 831A93858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661781758; 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=DcjkxQA/jWfIHoqnB1SD4qsCUg7oTn8a8DRED3AeUPA=; b=TD+117ovaZQdiZMAtmQjcWo1zP0+j+rpASianpEIL5u85zxebEb68jZACtSTJI1BUA83z5 9MR8zipVWVyFvMyPxgh/kYu5BRU5/AiyFboNbPAP6EmaMXFJ89w5jWCQ7D+iVnzAxWe5z9 p4N797spyMb3wV+DHDoa4wmLISvgw74= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-477-CUj7Pq5kP_2UV4CakejSEw-1; Mon, 29 Aug 2022 10:02:37 -0400 X-MC-Unique: CUj7Pq5kP_2UV4CakejSEw-1 Received: by mail-qt1-f197.google.com with SMTP id o22-20020ac85a56000000b0034481129ce6so6455208qta.19 for ; Mon, 29 Aug 2022 07:02:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc; bh=DcjkxQA/jWfIHoqnB1SD4qsCUg7oTn8a8DRED3AeUPA=; b=ym5b6IFwsplTcdyK94nvxrUIfN8wpE7NA4/gwlWoW/+jF/gNDrBk+YvHLQIxS9OecS z68DzaVuf29h6Cr+nLgX8K1ZLqmJsM69k9w2ozinzeVXbA2tnvKlxbsZ/4szPKzpkApP RU9TrVvr71tnAEpqxygirm84YjO2VKJWAGkQr/bgZZ4+Me+dm/yu/q4mm9opXT6zAKmH SdNN/0XX6zexEXkq/lJSewrMqypFjac1tmQLC/3Y6F1GSVjVv8eepFSpebKNOR4jTRwo C1jaqQK3dULzbkf2lZDkejJR/IEvdaFxye1pMOe2LnRuzQHYmJHtid4/8eTF3yZABzW9 VoZw== X-Gm-Message-State: ACgBeo2L0+62b8B1Ff9wTz96k5XjwXsWbK91dBfzVNJTlYI43gxqy4LS tUFZiDxxNgEUsmTvsKr92gWmPZvI6WAubAsNCMCRzWIVkrNNqG5Ek8QXTSLG5y0HwGrtwa0qMlG vxAxfZgdu6eG3vG044i9P X-Received: by 2002:a37:88c3:0:b0:6b9:53c7:75e4 with SMTP id k186-20020a3788c3000000b006b953c775e4mr8145384qkd.532.1661781756833; Mon, 29 Aug 2022 07:02:36 -0700 (PDT) X-Google-Smtp-Source: AA6agR5D6nbWZCvKefew8sBMm0kiTb+SKD1HtTMzzNSi/q0SNoWRiwq9dwcIJCo5lILYXmk9VgcoMA== X-Received: by 2002:a37:88c3:0:b0:6b9:53c7:75e4 with SMTP id k186-20020a3788c3000000b006b953c775e4mr8145355qkd.532.1661781756504; Mon, 29 Aug 2022 07:02:36 -0700 (PDT) Received: from [192.168.0.241] (192-0-145-146.cpe.teksavvy.com. [192.0.145.146]) by smtp.gmail.com with ESMTPSA id bq36-20020a05620a46a400b006b929a56a2bsm5978162qkb.3.2022.08.29.07.02.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Aug 2022 07:02:35 -0700 (PDT) Message-ID: <18876781-cfc5-2479-a7c4-baa12e3c9abe@redhat.com> Date: Mon, 29 Aug 2022 10:02:34 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v3] debug: test for more required cacellation points (BZ# 29274) To: Adhemerval Zanella Netto , libc-alpha@sourceware.org Cc: Andreas Schwab References: <20220718164643.101781-1-adhemerval.zanella@linaro.org> <2972abfa-dfa7-c093-3c5d-9f73f0ff3983@redhat.com> <34df3473-a456-97ae-99f8-471536b0d95d@linaro.org> From: Carlos O'Donell Organization: Red Hat In-Reply-To: <34df3473-a456-97ae-99f8-471536b0d95d@linaro.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP,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 server2.sourceware.org List-Id: On 7/26/22 15:10, Adhemerval Zanella Netto wrote: > > > On 21/07/22 18:23, Carlos O'Donell wrote: >> On 7/18/22 12:46, Adhemerval Zanella wrote: >>> + >>> + /* This test is the early cancel version of the first test, and the intent >>> + is to have the cancellation happen at one of two regions: >>> + >>> + 1. Before the cancellable syscall registers cancellation. >>> + 2. After the cancellable syscall registers cancellation. >>> + >>> + This test will exercise if syscall cancellation registration is an atomic >>> + operation or not since the transition from the regions is designed to be >>> + atomic. >>> + >>> + We can not control when the cancellation happens, but it will happen in >>> + one of the two regions. The first test (the !only_early version) >>> + attempts to test the second region, while this test attempts to test the >>> + first regiont and the transition with some probability. */ >>> + for (int i = 0; i < array_length (tests); i++) >>> + { >>> + xpthread_barrier_init (&barrier, NULL, 2); >>> + /* Reset the counter for the cleanup handler. */ >>> + cl_called = 0; >>> + >>> + /* After this wait the cancellation handler is in place. */ >>> + pthread_t thr = xpthread_create (0, tests[i].tf, NULL); >>> + >>> + xpthread_cancel (thr); >>> + xpthread_barrier_wait (&barrier); >> >> Shouldn't this be: >> >> xpthread_barrier_wait (&barrier); >> xpthread_cancel (thr); >> >> You want to: >> >> (a) Make sure a cancellation handler is registered. >> (b) Deliver the signal *before* you reach the syscall __pthread_enable_asyncancel. >> (c) Observe the cancelled bit early and act upon it. >> >> The test is effectively very similar to the first test but with no wait to allow >> the thread to get to and block on the syscall. >> > In fact the ordering is correct because in this case there is no signal > involved, pthread_cancel will just mask the thread canceled > (CANCELING_BITMASK | CANCELED_BITMASK) since asynchronous mode is not set. > > Otherwise, pthread_cancel might be called when __pthread_enable_asyncancel > is already called (changing the mode to asynchronous), and the the signal > handler it will act, not __pthread_enable_asyncancel. You are correct. The pthread_barrier_wait call has no calls to cancelable futex APIs. The pthread_cleanup_push call is not itself a cancellation point either. Calling pthread_cancel first ensures the bit mask is set. Calling pthread_barrier_wait after ensures that we will always enter the cancellation region with the cancel bits set and verify that the thread sees the values set and cancels without delivery of a signal. In which case we need to rewrite the comments to match that. The comments for the early-test need to describe this behaviour. -- Cheers, Carlos.