[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EB7132F5A45D144AC896FC29A83F1920116E2A3@DGGEML501-MBX.china.huawei.com>
Date: Thu, 28 May 2020 14:27:55 +0000
From: tangyizhou <tangyizhou@...wei.com>
To: "dalias@...ifal.cx" <dalias@...ifal.cx>
CC: "musl@...ts.openwall.com" <musl@...ts.openwall.com>, "Wanghui (John)"
<john.wanghui@...wei.com>, "Huangshuai (OSLab)" <elvis.huang@...wei.com>
Subject: RE: Fix the return value of pthread_getschedparam in musl
libc
> 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. 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.
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.
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.
Yizhou
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
