From: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
To: "GNU C. Library" <libc-alpha@sourceware.org>,
Rich Felker <dalias@aerifal.cx>
Subject: [RFC] Propose fix for race conditions in pthread cancellation (bz#12683)
Date: Wed, 10 Sep 2014 21:48:00 -0000 [thread overview]
Message-ID: <5410C70E.70207@linux.vnet.ibm.com> (raw)
Hi all,
I have summarized in [1] the current issues with GLIBC pthread cancellation system,
the current GLIBC implementation and the proposed solution by Rich Felker with the
adjustment required to enabled it on GLIBC.
It is still heavily WIP and I'm still planning to add more content, so any question,
comments, advices are welcomed.
The GLIBC adjustment to proposed solution is in fact the current work I'm doing to
rewrite pthread cancellation subsystem [2]. My code still needs a *lot* of cleanup,
but initial results are promising. It is building on both powerpc64 and x86_64
(it won't build on others platforms basically because I rewrite the way cancelable
syscalls are done).
Current NPTL testcase are all passing but:
FAIL: nptl/tst-cancel-wrappers
FAIL: nptl/tst-cancel20
FAIL: nptl/tst-cancel21-static
FAIL: nptl/tst-cancel4
FAIL: nptl/tst-cancel5
FAIL: nptl/tst-cancelx20
FAIL: nptl/tst-cancelx21
FAIL: nptl/tst-cancelx4
FAIL: nptl/tst-cancelx5
FAIL: nptl/tst-detach1
The 'nptl/tst-cancel-wrappers' is expected since I get rid of the
enable_asynccancel/disable_asynccancel function, but the other are due the fact now
cancellation *will not* on one important case:
* syscall is blocked but with some side effects already having taken place (for
instance partial read/write/send/etc.)
This is the cases for tst-cancel[4/5] that checks for cancelable write and send
and the way the test is code, kernel IP address from signal handler is *after*
syscall, indicating partial read/send. Similar cases occurs for tst-cancel[20|21],
where the read returns after the syscall in pipe reading. I'm still checking
nptl/tst-detach1.
Anyway, now I would like comments about proposed solution and if the cases for
new failures should not be allowed or if testcases now should be adjusted.
I also note that this new implementation shows correct behavior on the testcases
from bug reported and replicated on bugzilla: first one does not show leaked
file descriptors and second correctly hangs.
[1] https://sourceware.org/glibc/wiki/Release/2.21/bz12683
[2] https://github.com/zatrazz/glibc/commits/master-bz12683
next reply other threads:[~2014-09-10 21:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-10 21:48 Adhemerval Zanella [this message]
2014-09-10 22:00 ` Rich Felker
2014-09-10 22:11 ` Adhemerval Zanella
2014-09-12 14:44 ` Torvald Riegel
2014-09-12 15:32 ` Rich Felker
2014-09-12 16:11 ` Torvald Riegel
2014-09-12 17:17 ` Rich Felker
2014-09-12 22:44 ` Torvald Riegel
2014-09-13 1:58 ` Rich Felker
2014-09-14 18:00 ` Torvald Riegel
2014-09-15 0:46 ` Rich Felker
2014-09-12 17:33 ` Joseph S. Myers
2014-09-14 18:04 ` Torvald Riegel
2014-09-17 22:13 ` Adhemerval Zanella
2014-09-15 12:49 ` Florian Weimer
2014-09-15 14:39 ` Torvald Riegel
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=5410C70E.70207@linux.vnet.ibm.com \
--to=azanella@linux.vnet.ibm.com \
--cc=dalias@aerifal.cx \
--cc=libc-alpha@sourceware.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).