From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: Sometimes when recv() is interrupted by a signal (e.g. SIGUSR1), it returns not EINTR as expected, but EAGAIN. This happens sporadically, but the attached reproducerar reproduced the problem within a few seconds. Version-Release number of selected component (if applicable): kernel-2.4.21-15.EL How reproducible: Always Steps to Reproduce: 1. Run the attached reproducer. 2. 3. Actual Results: [magnusi@stheng30:~]$ ./test_select_ia64 recv returned EAGAIN, after 132981248 bytes and 80 interrupts recv returned EAGAIN, after 291813888 bytes and 137 interrupts recv returned EAGAIN, after 8419840 bytes and 4 interrupts recv returned EAGAIN, after 6356992 bytes and 3 interrupts recv returned EAGAIN, after 4243456 bytes and 2 interrupts ... etc Expected Results: No output should have been written, since recv should not have returned EAGAIN. Additional info: This only happens on SMP machines. It is confirmed to happen on both i386 and ia64.
Created attachment 110282 [details] Reproducer.
Created attachment 110485 [details] Fix for EAGAIN signal race Pretty tight race. We were returning -EAGAIN when the recv queue is non-empty.
A fix for this problem has just been committed to the RHEL3 U5 patch pool this evening (in kernel version 2.4.21-27.12.EL).
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-294.html