bugThe GNU Hurd - Bugs: bug #22861, bogus answer from pflocal to...

 
 

bug #22861: bogus answer from pflocal to io_select SELECT_URG

Submitted by:  None
Submitted on:  Sun 06 Apr 2008 11:52:50 PM UTC  
Votes:  1  
 
Category: Hurd ServersSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: NonePrivacy: Public
Assigned to: NoneOriginator Name: 
Originator Email: -unavailable-Open/Closed: Open
Reproducibility: NoneSize (loc): None
Planned Release: NoneEffort: 0.00
Wiki-like text discussion box: 

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sat 16 Jul 2016 01:46:37 PM UTC, comment #4:

The t/io_select_timeout patches in glibc complicate the fix. Now if glibc/hurd/hurdselect.c (_hurd_select) is called with a timeout and at least one file descriptor, it passes the current time + the timeout to the servers, instead of letting __mach_msg time out. And if each server returns MIG_NO_REPLY to its message loop and so never sends a reply, then _hurd_select sleeps until interrupted by a signal, regardless of what the timeout was.

I guess the io_select_timeout implementation in each server could just wait until the timeout occurs (at which time it would send an reply with select_type=0) or the reply port dies (in which case no reply can be sent, and any related resources should be freed). As an optimization, the server could use a timer queue so that the wait does not tie up a thread.

io_select could be implemented in a similar way except with an infinite timeout, or it could be done with MIG_NO_REPLY as originally planned, I think.

I removed the workaround from ELinks and tried to reproduce the original problem but couldn't; it never called select in such a way that the pipe was only in exceptfds. To test any fix here, one should construct a dedicated test program instead of relying on ELinks.

Kalle Olavi Niemitalo <kon>
Wed 13 Jul 2016 08:09:43 PM UTC, comment #3:

MIG_NO_REPLY is defined in gnumach and handled properly by the msg routines, yes.

It could work indeed, could you give it a try?

Samuel Thibault <sthibaul>
Project Member
Tue 12 Jul 2016 09:17:17 AM UTC, comment #2:

About alternative (c) in the original submission: MIG_NO_REPLY is checked in glibc/mach/msgserver.c (__mach_msg_server_timeout), which hurd/libports/ calls. That might actually work then.

Kalle Olavi Niemitalo <kon>
Sun 02 Nov 2008 05:43:11 PM UTC, comment #1:

ELinks 0.12pre2 includes a workaround in set_handlers():

  • Hurd bug 22861: Work around select() falsely reporting exceptions in pipes.

The workaround slows ELinks down a bit, so it may be reverted after this Hurd bug has been fixed.

Kalle Olavi Niemitalo <kon>
Sun 06 Apr 2008 11:52:50 PM UTC, original submission:

If a program first calls pipe() and then calls select() in such a way that one of the pipe file descriptors is in exceptfds but not in readfds nor writefds, the select() call returns almost immediately and leaves the pipe in exceptfds, as if an exception had occurred there. This bug completely wrecks the ELinks web browser, which uses a pipe for internal communication and ends up closing the pipe because it thinks an error has occurred.

rpctrace shows that _hurd_select in glibc sends an io_select_request (4) to pflocal and gets back io_select_reply (0 0), which it considers a "bogus answer": if the pipe is not ready for any I/O, then it should not have responded yet. And so, glibc substitutes SELECT_ALL, which includes SELECT_URG.

Why did pflocal send the bogus answer, then? When select_type is initially SELECT_URG without other flags, S_io_select in hurd/pflocal/io.c first resets select_type to zero and then calls pipe_pair_select in hurd/libpipe/pipe.c. That notices select_type is neither SELECT_READ nor SELECT_WRITE, and apparently assumes it is SELECT_READ | SELECT_WRITE and waits for either condition. One of the conditions is satisfied, but select_type remains zero, and S_io_select then propagates the zero to io_select_response.

Possible fixes:

(a) Change _hurd_select in glibc to completely ignore responses that have select_type=0. I.e. change the protocol so that a server can send back io_select_reply (0 0) to mean that the requested events cannot ever occur. This would however make the timeout in _hurd_select more complex to implement. Currently, _hurd_select simply passes the timeout to Mach when waiting for the first response to the io_select_requests it has sent out; after getting the first response, it collects any further replies with a zero timeout, and then returns. If _hurd_select were changed to ignore the first response in some cases, it would have to keep track of how much time it has spent.

(b) Change pflocal to detect when io_select_request is asking solely for events that cannot ever occur, and sleep until the caller closes the reply port. Similar changes may be needed in other servers. The downside is that this would needlessly tie up a thread in the server.

(c) As in (b) but instead of sleeping, discard the right to the reply port without sending any response, and return the thread to more productive use. However, there seem to be two problems with this. Firstly, it may be difficult to make MIG-generated stubs let the server skip the response. The Mach 3 Server Writer's Guide mentions that the server routine can return MIG_NO_REPLY to to this, but I did not find that symbol in the GNU MiG 1.3 sources. Secondly, discarding the reply right might trigger a no-senders notification in the client. It appears though that _hurd_select does not currently request such notification.

This bug was discussed in December 2007 on the debian-hurd and elinks-dev mailing lists, under the subject "The Links/Links2/ELinks browsers are unusable on Debian GNU/Hurd".

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by sthibaul (Posted a comment)
  • -unavailable- added by kon (Posted a comment)
  • -unavailable- added by kon
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 1 encouragement so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 02 Nov 2008 05:43:11 PM UTCkonCarbon-Copy-=>Added kon

    Back to the top


    Powered by Savane 3.1-cleanup