I will summarize this and resubmit - but I think I need to stress a point
separately...
I am not personally aware of any problems which have been traced back to the
interaction of usleep and nanosleep on Linux - in fact on Linux itself
this may not be
an issue at all.
usleep and nanosleep historically were based on two different underlying
timer subsystem designs, and the safe interaction between those timer
subsystems is implementation-dependent.
Therefore the intermixing of usleep and nanosleep calls is an issue for
strict POSIX compliance and portability across POSIX platforms -
however it is unlikely to be causing problems in Linux applications.
So please consider this patch as a cosmetic and portability issue
rather than a fix for any immediate vulnerability in LTP code.
On Tue, Jul 29, 2014 at 1:16 PM, <chru...@suse.cz> wrote:
> Hi!
> > > > Replaced deprecated usleep calls with calls to rt_nanosleep,
> > > > which has no potentially adverse interactions with signals.
> > >
> > > Deprecated in which sense? In terms of realtime testsuite?
> > >
> >
> > My apologies for being ambiguous... years of writing pthreads
> applications
> > has made this function 'deprecated' by default in my thinking.
> > usleep should generally be avoided when using many other timer functions
> > - including nanosleep, which is the basis of rt-nanosleep.
> > Generally speaking, usleep and nanosleep should not be used in the same
> > program.
> >
> > Its interaction with SIGALRM may cause interference
> > with other functions using SIGALRM, if any are in use.
> >
> > As indicated in the usleep() man page NOTES:
> > " The interaction of this function with the SIGALRM signal, and
> > with
> > other timer functions such as alarm(2), sleep(3),
> > nanosleep(2),
> > setitimer(2), timer_create(2), timer_delete(2),
> > timer_getoverrun(2),
> > timer_gettime(2), timer_settime(2), ualarm(3) is unspecified.
> > "
>
> Ok.
>
> > > Has usleep() caused the test to fail? If so, why?
> > >
> > > usleep() is not causing prio-wake test failures in our environment.
> >
> > We are getting race conditions among multiple waiter threads
> > on armv7a processors in the futex / mutex locking code
> > for the mutex associated with the condition variable in prio-wake.
> > This is causing one of the threads to 'hang' waiting for a lock
> > after the lock owner releases it and terminates. Since this
> > doesn't happen on x86 it appears to be specific to the armv7a -
> > either in the compiler code generation or in some arch-specific
> > code somewhere... we are investigating.
> >
> > In investigating possible reasons for the 'hangup' I began by
> > examining the source in prio-wake.c and saw the potentially
> > problematic usleep calls. Knowing they don't always play
> > well with nanosleep I eliminated them on the chance that
> > they were contributing to the hangups... which in this case
> > they are not.
> >
> > However as I said, years of coding pthreads apps
> > with various timer functions has led me to use only
> > nanosleep-related timer functions and to avoid usleep
> > altogether - so I submit this patch as a somewhat
> > 'nit-picking' minor cleanup.
>
> Ok.
>
> Can you please sumarize this a bit so that it fits into the commit
> message and resend the patch?
>
> --
> Cyril Hrubis
> chru...@suse.cz
>
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
