On Sun, May 03, 2009 at 01:57:16PM -0700, Marco S Hyman wrote:
quoted text
> On May 3, 2009, at 12:26 PM, Tobias Ulmer wrote:
>
>> I'm currently trying to get rthreads pass regress/lib/libpthread.
>> Currently I'm stuck at blocked_dup2.c and could use a pair of
>> helpful eyes that can confirm that the testcase that is wrong, not
>> the kernel.
>>
>> Comments inline, unimportant code removed, file means "struct file".
>
> Some of the "unimportant code" may be important.  I think you are  
> running
> into the difference between the pthread wrapper around recvfrom and
> what the kernel actually oes.
>
> Your comment
>
> 	/* 2. iteration: close newfd, f_count goes down to 1,
> 	   then up again. fd always stays a valid descriptor,
> 	   we block on pthread_join until the end of time.
>           testcase panics.
> 	*/
>
> describes the kernel, no?.  In the case of pthreads I believe there is
> a context switch between the close of newfd and the subsequent dup.
> Or perhaps it is just that the pthread "closing_fd" is updated  
> incorrectly.
> In any case uthread_recvfrom.c has this bit of code when checking why it
> woke up:
>
>                                 /* Check if the wait was interrupted: */
>                                 if (curthread->interrupted) {
>                                         /* Return an error status: */
>                                         errno = EINTR;
>                                         ret = -1;
>                                         break;
>                                 } else if (curthread->closing_fd) {
>                                         /* Return an error status: */
>                                         errno = EBADF;
>                                         ret = -1;
>                                         break;
>                                 }
>
> The fd is closing, EBADF is returned.   That is always true of pthreads.
> Dunno about the kernel code.
>
> // marc

I'm only interested in what the kernel does and all the comments refer
to the kernel side of things. I know userland pthreads passes this test,
but I'm arguing that this is wrong.

Pthreads do use sys_dup2 internally and debugging output shows that the
underlying object of newfd is never really closed. The EBADF is
simulated by pthreads even though the object is perfectly valid.

This sort of context sensitive information isn't available to the kernel.

Btw lets say the kernel does the "right" thing and closes the object
pointed by newfd (in the 2nd iteration) and notifies the threads with a
EBADF like pthread does. Remember that fd and newfd point at the same
object? That would mean in the third iteration, dup2 errors out with
EBADF and so does recvfrom. Testcase fails (and a few other things, as
you can easily imagine).