From: "Will Deacon" <will.deacon@arm.com>
To: 'Garrett Cooper' <yanegomi@gmail.com>
Cc: ltp-list@lists.sourceforge.net
Subject: Re: [LTP] [PATCH] Fix rt_sigtimedwait ordering test
Date: Fri, 25 Feb 2011 10:53:48 -0000 [thread overview]
Message-ID: <000901cbd4da$4a2949d0$de7bdd70$@deacon@arm.com> (raw)
In-Reply-To: <AANLkTikTY4X+q8iv6PBkiQbbA6MdJARCUOEr45JKPkTf@mail.gmail.com>
Hi Garrett,
> > I've not heard anything further on this, but it does fix a real issue
> > on the platform I'm using. Do you need anything more from me for this
> > to be considered for committing?
>
> Kind of odd that only doing it there would fix the entire testcase
> as that's not the only pattern of
>
> create_sig_proc(...)
>
> that isn't handled with a wait/waitpid.
It's not that strange because, in this testcase at least, we call
sigwaitinfo either with a timeout or a sigset_t in the parent. In
the latter case this will block until the signal is delivered so
the race between child and parent isn't a problem.
> It just seems like there are tons of bugs lurking under the scenes
> with this create_sig_proc deal because it doesn't wait, and if the
> parent doesn't wait, then you're just creating a ton of races
> potentially if not handled properly.
The issue is when you have multiple children and the test relies
on a specific ordering of signal delivery (as is the case for RT
signals).
> FWIW some more synchronization may need to be added in
> create_sig_proc (like blocking I/O with a pipe for instance, mq_*,
> sem_*? mq_* and sem_* are kind of undesirable though because those
> APIs are buggy on different architectures / versions of Linux, and
> pipes are generally simple enough to express synchronization), in
> order to ensure that things are deterministically ordered and the
> results of the test are sane.
I'm not sure this is necessary because it restricts the concurrency
for testcases where the race shouldn't matter.
Will
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
prev parent reply other threads:[~2011-02-25 10:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-07 14:28 [LTP] [PATCH] Fix rt_sigtimedwait ordering test Will Deacon
2011-02-16 16:43 ` Will Deacon
[not found] ` <9151393516569896904@unknownmsgid>
2011-02-23 8:02 ` Garrett Cooper
2011-02-25 10:53 ` Will Deacon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000901cbd4da$4a2949d0$de7bdd70$@deacon@arm.com' \
--to=will.deacon@arm.com \
--cc=ltp-list@lists.sourceforge.net \
--cc=yanegomi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox