This is the mail archive of the libc-alpha@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]

Re: [PATCH] [BZ #19402] Clear list of acquired robust mutexes in the child process after forking.


On 01/13/2017 04:37 PM, Torvald Riegel wrote:
On Fri, 2017-01-13 at 14:11 +0100, Florian Weimer wrote:
On 12/23/2016 10:31 PM, Torvald Riegel wrote:
Can we add a test case for this?
What do you have in mind?  Checking that the list is reset to zero after
fork?  Do we need a test for that if we have documented the need to do
that in the code?

What about the attached patch?

That looks fine generally, with the following exceptions / comments:

According to the feedback so far we got for
http://austingroupbugs.net/view.php?id=1112 the trylock-based test is
actually UB.  There should be a comment making that clear (ie, that we
rely on something we know about our current implementation to test
this).

Yeah, I'll move the check to the parent process and add another bit for error-checking mutexes (and make the test conditional on that).

If this was a multi-threaded test program, it would be invalid because
non-async-signal-safe functions are executed in the child before exec()
is called.  In a single-threaded program, it's not quite clear to me
what POSIX really wants.  There's indication that only AS-safe functions
should be called, but IIRC that's not explicitly stated.
Florian says we still need to support this as an extension.  If so, this
should be made clear in the test (using a suitable comment).

I'll add a comment, yes.

What about putting the x* wrappers as static inline functions just in
the header?  Then, we wouldn't need to add all those trivial C files.

We did that before and it caused problems because it restricted what feature macros we could assume in the implementation of those inline functions.

I verified your patch with this test, so I think it is okay to check it in. I'll commit my updated patch afterwards.

Thanks,
Florian


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