This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/14717] Allow choice of clock source for calls to sem_timedwait() and pthread_mutex_timedwait().


https://sourceware.org/bugzilla/show_bug.cgi?id=14717

--- Comment #7 from Grotlek <grotlek at hotmail dot com> ---
Hi,

I am going to assume it's not possible to use a similar method to the PThread
conditionals then; shame.

As it stands (although I've not tested either - this paragraph at the moment is
hypothetical) it's potentially possible for any process with the permission to
set the clock to effectively hang other processes (DoS) by using a "while(1)
adjtime(..);" call or by "abuse" of an upstream NTP server achieve the same
thing. (Although admittedly, there would be two problems if this were to happen
;-). Doubly so if the processes use the timeout to actually do background work
(which would no longer get done).

However, now three of us have seen this problem on a smaller scale in real use
(myself and two other commenters), the bug is clearly not just hypothetical.

Is it worth someone who understands the underlying code better (hint, probably
not me because I could not be sufficiently pedantic with the description :-),
pushing this into the kernel bug tracker?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]