From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5158 invoked from network); 28 May 2020 16:09:33 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 28 May 2020 16:09:33 -0000 Received: (qmail 3640 invoked by uid 550); 28 May 2020 16:09: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 3616 invoked from network); 28 May 2020 16:09:31 -0000 Date: Thu, 28 May 2020 12:09:18 -0400 From: "dalias@aerifal.cx" To: tangyizhou Cc: "musl@lists.openwall.com" , "Wanghui (John)" , "Huangshuai (OSLab)" Message-ID: <20200528160918.GX1079@brightrain.aerifal.cx> References: <4EB7132F5A45D144AC896FC29A83F192011602E1@DGGEML521-MBS.china.huawei.com> <20200520155046.GK1079@brightrain.aerifal.cx> <4EB7132F5A45D144AC896FC29A83F192011628FB@DGGEML521-MBS.china.huawei.com> <20200522022628.GP1079@brightrain.aerifal.cx> <4EB7132F5A45D144AC896FC29A83F1920116E2A3@DGGEML501-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB7132F5A45D144AC896FC29A83F1920116E2A3@DGGEML501-MBX.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Fix the return value of pthread_getschedparam in musl libc On Thu, May 28, 2020 at 02:27:55PM +0000, tangyizhou wrote: > > There's not such an issue. t->killlock is held so that this can't > > happen, and more importantly, so that the thread can't exit and > > the tid be reassigned to a new thread or process that would > > wrongly be acted upon. > > Sorry for late reply. > > t->killlock is held only in pthread functions, and it won't work in > the following situation. Assuming process A is running on CPU core > 0, process B is running on CPU core 1, process C is running on CPU > core 2. Process A calls pthread_getschedparam() to query the > information of process B. This is not possible. pthread_getschedparam operates on threads not processes. A pthread_t is only valid in the context of a process. There is simply no way to pass a pthread_t for a thread in a different process, because the identifiers are in a separate space. Two pthread_t values could be numerically identical but refer to completely different threads, or one of them be invalid, just because they're local to the process -- and mechanically, the address space -- they're in. > After SYS_sched_getparam succeeds and > before SYS_sched_getscheduler starts, we assume the scheduling > timeslice of A is running out, then A is put in the runqueue of the > kernel. This is a chance for C to call kill() to kill B. When A is > running again, SYS_sched_getparam returns -ESRCH. You seem to be confusing threads and processes. kill signals processes not threads. It's possible to send a signal to a particular thread; there's a standard interface to do this within a process, pthread_kill, and you could go outside the standard interfaces and do it cross-process using kernel tids with tkill. But that does not cause the thread to cease to exist. It makes a signal pending for the thread, and depending on the action for that signal, it may either cause a signal handler to run or cause *the whole process* to terminate. There is no way to forcibly terminate a single thread, from within the same process or a different one, short of UB or using trace/debugging type interfaces to attach to the process and do bad things to it. > Process B may be terminated due to other reasons when A is put in > the runqueue. For example, B is running and encounters a bus error, > then B is terminated because of SIGBUS signal. If SIGBUS is not caught, the whole *process* terminates, not the thread. > It very hard to see these situations, but they exist in a > theoretical way. There isn't such an issue for the implementation of > pthread_getschedparam() of glibc. These are non-issues based on your misunderstanding of what threads are. Rich