From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 916cafca for ; Thu, 16 Jan 2020 13:44:34 +0000 (UTC) Received: (qmail 32418 invoked by uid 550); 16 Jan 2020 13:44:32 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32400 invoked from network); 16 Jan 2020 13:44:31 -0000 Date: Thu, 16 Jan 2020 08:41:47 -0500 From: Rich Felker To: "zhaohang (F)" Cc: "musl@lists.openwall.com" , pengyuanhong Message-ID: <20200116134147.GM30412@brightrain.aerifal.cx> References: <59FB1E003EF3A943BD6BAD197ABD4D6A349C51@dggemi524-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59FB1E003EF3A943BD6BAD197ABD4D6A349C51@dggemi524-mbx.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] some doubts about pthread_cancel On Thu, Jan 16, 2020 at 12:41:25PM +0000, zhaohang (F) wrote: > Hi, > > I have two doubts about pthread_cancel in musl v1.1.22. > > static void cancel_handler(int sig, siginfo_t *si, void *ctx) > { > pthread_t self = __pthread_self(); > ucontext_t *uc = ctx; > uintptr_t pc = uc->uc_mcontext.MC_PC; > a_barrier(); > if (!self->cancel || self->canceldisable == PTHREAD_CANCEL_DISABLE) return; > > 1. If try to cancel a thread which is asynchronous and > cancel-disable, the handler of SIGCANCEL will return directly here > and it seems that the cancellation request is not remained queued. > It makes me confused how this thread will be assured to cancel after > it enables cancellation? self->cancel remains true, so the request will be acted upon at the next cancellation point. If your concern is that it won't be acted upon as soon as the cancellation state is set back to enabled, I believe that's correct, but there's no requirement for async cancellation to happen sooner than deferred, only an allowance. If you think this is a practical problem/QoI issue, pthread_setcancelstate could be made to check for somethig like new==PTHREAD_CANCEL_ENABLE && self->cancelasync && self->cancel and to act on it in that case. > _sigaddset(&uc->uc_sigmask, SIGCANCEL); > if (self->cancelasync || pc >= (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end) { > uc->uc_mcontext.MC_PC = (uintptr_t)__cp_cancel; > #ifdef CANCEL_GOT > uc->uc_mcontext.MC_GOT = CANCEL_GOT; > #endif > return; > } > __syscall(SYS_tkill, self->tid, SIGCANCEL); > > 2. Why send SIGCANCEL again here? I think self->cancel is enough to > judge whether a deferred thread has been cancelled, and furthermore > SIGCANCEL is added to uc->uc_sigmask so that SIGCANCEL will not be > handled again. } It's needed for the corner case where SIGCANCEL arrives during a signal handler that's interrupted a cancellation point. The SIGCANCEL handler has determined that cancellation is not to be acted upon now, but when the other signal handler (the one it interrupted) returns, whether to act needs to be evaluated again since it might return to a point between the evaluation of self->cancel and the syscall (including restarting the syscall itself) in __syscall_cp_asm. By re-raising SIGCANCEL but returning from the SIGCANCEL handler with it blocked, the handler sets up for it to be unblocked atomically with return of the first signal handler and thereby re-run when the first signal handler returns. This cascades for arbitrary levels of nested signal handlers. Rich