From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-1.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 87ECC200B9 for ; Tue, 8 May 2018 13:35:19 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=DYst A70u4rJEY9cgdvrwzUavQic08Pqrj2djNoWI+99cT+eJ4nL18Dw7yML3QH9OiyQE RIMpxenIaXN2QFTogLeVQa3Tf9vmWSD4o0xWUbGnSMaymS5DDzKeArWAyP/o7VRN t1b2Q19Nxw1CLGanPanlYkwcW613cgMFPXYcr8A= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; s=default; bh=cg/h7ituKp h/TZwHnBKFnWR1NbA=; b=r9uM67wIDht27v7SN1pWfk0NDsKFV+hOS7Ye0eJIA9 fg2ic39ujnrA0ffT3sn8Fyy2B7gjERsBuSZnrLiifIkLlI7SrJtJGc6eeYAa0b9d nduedEaTUavaTmn2EFVCfxa+8gSGX3v4SD1jUeJ/4T6cbN2Rqzv6hu2RdviCNUdA s= Received: (qmail 30917 invoked by alias); 8 May 2018 13:35:17 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 30906 invoked by uid 89); 8 May 2018 13:35:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-HELO: mailbackend.panix.com X-Gm-Message-State: ALQs6tAqCXUrAkOop3e9Q9kbrWgkRHm22mQCH8NBK6nLFIH5EJJh4ORO /N47DcCezIjvsW7bmANJKwiUKgcyWQWzEhzwoCM= X-Google-Smtp-Source: AB8JxZqqZRo3EejRFrL3RwoW5mJ0GUTD3SraaLvNguLsQ+WQwfi53hiFHMi08PeFRkX9/9Kao6vxUxBLsaOyUPdF8II= X-Received: by 2002:aca:5d8a:: with SMTP id r132-v6mr16206109oib.41.1525786511802; Tue, 08 May 2018 06:35:11 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20180507024909.5598-1-zackw@panix.com> <20180507024909.5598-2-zackw@panix.com> From: Zack Weinberg Date: Tue, 8 May 2018 09:35:11 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 02/21] nptl: Fix testcases for new pthread cancellation mechanism To: Adhemerval Zanella Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" On Mon, May 7, 2018 at 1:13 PM, Adhemerval Zanella wrote: > On 06/05/2018 23:49, Zack Weinberg wrote: >> On 26 Feb 2018, Adhemerval Zanella wrote: >>> For tst-cancel{2,3} case it remove the pipe close because it might >>> cause the write syscall to return with side effects if the close is >>> executed before the pthread cancel. >> >> ... however, this change appears to be wrong. If cancellation is >> broken, these tests will now deadlock rather than failing cleanly. > > On current cancellation implementation the thread will finish regardless > and sigcancel_handler will act whether there is side-effects or not > (the pipe close). The issue is cancellation should not happen if syscall > returns but some side effects already took place, in this case the pipe > close. I think maybe I didn't explain clearly enough what I'm worried about here. What the test case does _when cancellation works_ is sensible. But this is a test case, it also needs to behave sensibly when cancellation _doesn't_ work. Imagine a new port where, for some reason, the cancellation mechanism is so broken that read/write aren't acting as cancellation points at all. Without the close, tst-cancel{2,3} will block forever in read/write. We have the test-driver timeout as a backstop, but we shouldn't rely on it. > Yes, although for this specific case I am not sure if this could happen > in practice. I assume if a thread issues a 'signal' followed by a 'close', > the signal target thread will receive the events in a ordered manner, i.e, > the signal handler will be activated before the syscall sees any > side-effects (the close). It seems to be Linux behaviour, but I am not > sure if a different system might act differently. I don't think POSIX makes any requirements, but yes, in practice the signal should always arrive first. > And I try to avoid the timing check, such as pthread_timedjoin_np, > because they tend to quite fragile in practice for such cases (due either > to system load when testing glibc, machine performance, etc.). This is reasonable. For the new cancellation mechanism in general, we don't have a good way of arranging for SIGCANCEL to arrive at exactly the critical points within the syscall sequence, do we? I am tempted to try to write a test case that scripts gdb and single-steps through a call to open() and fires SIGCANCEL at each instruction. >> won't it? I think teaching the backtrace logic about this would be >> better than needing to use a raw syscall() and then mess with the >> PowerPC implementation of syscall(). I might feel differently about >> this change if __read_nocancel were a public API, but it isn't... > > With your current suggestion to powerpc syscall bits, there is no need > to actually change the powerpc syscall implementation besides an > additional CFI mechanism. But I do not mind to change the testcase on > the bz12683 fix itself, the only advantage I see is by using indirect > syscall there is no need to actually change it again. I don't feel especially strongly about this now we have a way that doesn't add actual instructions to powerpc syscall(). zw