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, HTML_MESSAGE,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 10dd3d4a for ; Thu, 16 Jan 2020 12:41:49 +0000 (UTC) Received: (qmail 5904 invoked by uid 550); 16 Jan 2020 12:41:47 -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 5866 invoked from network); 16 Jan 2020 12:41:45 -0000 From: "zhaohang (F)" To: "musl@lists.openwall.com" CC: pengyuanhong Thread-Topic: some doubts about pthread_cancel Thread-Index: AdXMafZ/zOEjFqUMQV65t+RUVz+C2A== Date: Thu, 16 Jan 2020 12:41:25 +0000 Message-ID: <59FB1E003EF3A943BD6BAD197ABD4D6A349C51@dggemi524-mbx.china.huawei.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.221.92] Content-Type: multipart/alternative; boundary="_000_59FB1E003EF3A943BD6BAD197ABD4D6A349C51dggemi524mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [musl] some doubts about pthread_cancel --_000_59FB1E003EF3A943BD6BAD197ABD4D6A349C51dggemi524mbxchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 =3D __pthread_self(); ucontext_t *uc =3D ctx; uintptr_t pc =3D uc->uc_mcontext.MC_PC; a_barrier(); if (!self->cancel || self->canceldisable =3D=3D PTHREAD_CANCEL_DIS= ABLE) 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 cancel= lation request is not remained queued. It makes me confused how this thread= will be assured to cancel after it enables cancellation? _sigaddset(&uc->uc_sigmask, SIGCANCEL); if (self->cancelasync || pc >=3D (uintptr_t)__cp_begin && pc < (u= intptr_t)__cp_end) { uc->uc_mcontext.MC_PC =3D (uintptr_t)__cp_cancel; #ifdef CANCEL_GOT uc->uc_mcontext.MC_GOT =3D CANCEL_GOT; #endif return; } __syscall(SYS_tkill, self->tid, SIGCANCEL); 2. Why send SIGCANCEL again here? I think self->cancel is enough to judge w= hether a deferred thread has been cancelled, and furthermore SIGCANCEL is a= dded to uc->uc_sigmask so that SIGCANCEL will not be handled again. } --_000_59FB1E003EF3A943BD6BAD197ABD4D6A349C51dggemi524mbxchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I have two doubts about pthread= _cancel in musl v1.1.22.

static void cancel_handler(int = sig, siginfo_t *si, void *ctx)

{

&= nbsp; pthread_t self =3D __pthread_self();

&= nbsp; ucontext_t *uc =3D ctx;

&= nbsp; uintptr_t pc =3D uc->uc_mcontext.MC_PC;

&= nbsp; a_barrier();

&= nbsp; if (!self->cancel || self->canceldisable =3D= =3D PTHREAD_CANCEL_DISABLE) return;

1. If try to cancel a thread wh= ich is asynchronous and cancel-disable, the handler of SIGCANCEL will retur= n 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?=

&= nbsp; _sigaddset(&uc->uc_sigmask, SIGCANCEL);=

&= nbsp; if (self->cancelasync || pc >=3D (uintpt= r_t)__cp_begin && pc < (uintptr_t)__cp_end) {<= /p>

&= nbsp; uc-&= gt;uc_mcontext.MC_PC =3D (uintptr_t)__cp_cancel;

#ifdef CANCEL_GOT

&= nbsp; uc-&= gt;uc_mcontext.MC_GOT =3D CANCEL_GOT;

#endif<= /p>

&= nbsp; retu= rn;

&= nbsp; }

&= nbsp; __syscall(SYS_tkill, self->tid, SIGCANCEL);=

2. Why send SIGCANCEL again her= e? 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.

}

--_000_59FB1E003EF3A943BD6BAD197ABD4D6A349C51dggemi524mbxchina_-- 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