This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/14829] sched_* functions wrongly alter thread scheduling, rather than process
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 17 Jun 2013 20:02:31 +0000
- Subject: [Bug libc/14829] sched_* functions wrongly alter thread scheduling, rather than process
- Auto-submitted: auto-generated
- References: <bug-14829-131 at http dot sourceware dot org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=14829
--- Comment #4 from Rich Felker <bugdal at aerifal dot cx> ---
On Mon, Jun 17, 2013 at 07:34:51PM +0000, carlos at redhat dot com wrote:
> The only uses which would break are AFAICT:
>
> * tgkill
> - Which could be enhanced to accept a tid, find the tgid, and then kill the
> associated group.
>
> * rt_tgsigqueueinfo
> - Same problem.
>
> They can be solved because the expected semantics is that you call these for a
> thread group, and if you instead pass a tid, it is a one-way translation from
> thread to thread group. Even with cgroups I don't think this invariant is
> broken.
>
> Did I miss anything?
Yes. getpid() uses the cached pid from the TCB. So if set_tid_address
returned the tid, then getpid() would return the wrong pid. On the
other hand, if set_tid_address returned the pid, and all syscalls that
accept tids would also accept a pid and treat it as the tid of the
initial thread in that process, then things might not be so bad, but I
think there might be risks involved in threads having two distinct
identifiers, especially when the tid is used to mark the owner of a
synchronization object. I'm not sure that there would be problems with
this approach, but I still think it sounds risky.
--
You are receiving this mail because:
You are on the CC list for the bug.