Summary: | pselect implementation (when not implemneted by the kernel) agriviates the race | ||
---|---|---|---|
Product: | glibc | Reporter: | Shachar Shemesh <shachar> |
Component: | libc | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | REOPENED --- | ||
Severity: | normal | CC: | adhemerval.zanella, fweimer, glibc-bugs, mtk.manpages, neleai |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Attachments: |
Proposed patch to narrow the race window
Program demonstrating the problem |
Description
Shachar Shemesh
2009-02-04 10:05:33 UTC
Created attachment 3710 [details]
Proposed patch to narrow the race window
Proposed patch to the problem
Forgot to add - in the above patch, NSIG_LONGS is undefined. Here is its definition: // Number of __vals in sigset_t that actually contain useful data #define NSIG_LONGS (_NSIG/(8*sizeof(((sigset_t *)NULL)->__val[0]))) Shachar Created attachment 3712 [details]
Program demonstrating the problem
This program demonstrate the problem. Under a kernel with pselect support, it
prints:
sig_happened=1
sig_happened=1
sig_happened=1
sig_happened=1
sig_happened=1
And exits almost immediately.
Shachar, I suspect that it's not worth trying to make the fix you suggest. The fix will only appear in modern glibc, and any modern system will have a kernel-supported. The fundamental problem can't be remedied: the idea to add a userspace implementation of pselect() was extremely muddleheaded, and worsens portability problems for applications. The portability question goes from being "do I have pselect() or not?" to "do I have a pselect() or not, and if I do, is it one that works?"; the last part of the second question can only be verified with a check of the kernel (and glibc) versions. As according to http://lwn.net/Articles/176911/ pselect apperared at 2.6.16 and required kernel version is 2.6.16 this patch is moot now. On various architectures, pselect was only added in later kernel versions. Please carefully check *all* kernel-features.h files in glibc, or kernel sources of appropriate versions for *all* architectures, before making assertions about syscall availability. News sources likely to focus mainly on x86 are not sufficient. On Mon, Oct 14, 2013 at 02:24:37PM +0000, jsm28 at gcc dot gnu.org wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=9813
>
> Joseph Myers <jsm28 at gcc dot gnu.org> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status|RESOLVED |REOPENED
> Resolution|FIXED |---
>
> --- Comment #6 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
> On various architectures, pselect was only added in later kernel versions.
> Please carefully check *all* kernel-features.h files in glibc, or kernel
> sources of appropriate versions for *all* architectures, before making
> assertions about syscall availability. News sources likely to focus mainly on
> x86 are not sufficient.
Then patch in bugzilla is still valid. Could you review it and send to
libc-alpha?
Currently only microblaze-linux-gnu is affected by this issue and the faulty fallback code is not used when --enable-kernel=3.15 or newer is used. |