Bug 645528 - SIGPROF keeps a large task from ever completing a fork()
SIGPROF keeps a large task from ever completing a fork()
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.5
All Linux
high Severity high
: rc
: ---
Assigned To: Oleg Nesterov
Han Pingtian
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-21 13:57 EDT by Guy Streeter
Modified: 2016-02-09 20:33 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-21 06:12:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Reconstructed patch (1.99 KB, patch)
2015-05-08 07:32 EDT, Stefan Ring
no flags Details | Diff

  None (edit)
Description Guy Streeter 2010-10-21 13:57:12 EDT
A task using a lot of memory, and compiled with gprof, may never be able to complete a fork() because the timed (10 ms) profiling signal constantly causes the fork to be restarted.

This change appears to have been introduced by commit
4a2c7a7837da1b91468e50426066d988050e4d56
"make fork() atomic wrt pgrp/session signals"

Our customer considers this a kernel bug.
Comment 1 Guy Streeter 2010-10-21 13:58:14 EDT
Partial strace from reproducer:

11160 10:17:46.930243 --- SIGPROF (Profiling timer expired) @ 0 (0) ---
11160 10:17:46.930334 rt_sigreturn(0x1b) = 56 <0.000014>
11160 10:17:46.930406 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2b7acd3225a0) = ? ERESTARTNOINTR (To be restarted) <0.462230>
Comment 2 Guy Streeter 2010-10-21 13:59:16 EDT
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main()
{
long sz = 4.1*1024*1024*1024;
char *p = (char*)malloc(sz);
memset(p, 0, sz);
fork();
return 0;
}


If you save it to a file fork.c and compile with

/usr/bin/g++ -pg fork.c
Comment 4 Oleg Nesterov 2011-01-27 12:39:53 EST
Well. The problem is quite obvious. Everything is clear
and works "as expected". What is not clear to me is what
can we do ;) And given that SIGPROF can happen at any time
-pg can lead to the spurious (and perhaps unexpected) -EINTR
from other syscalls...

Otoh I understand why the customer dislikes this. I'll try
to think more...
Comment 14 RHEL Product and Program Management 2011-05-20 17:20:00 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 16 Jarod Wilson 2011-06-01 15:50:47 EDT
Patch(es) available in kernel-2.6.18-265.el5
You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5
Detailed testing feedback is always welcomed.
Comment 17 Han Pingtian 2011-06-16 00:17:39 EDT
Verified with -267.el5.
Comment 18 errata-xmlrpc 2011-07-21 06:12:47 EDT
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 therefore 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-2011-1065.html
Comment 19 Murali 2014-05-17 17:40:49 EDT
Hi,

Is it possible for anyone to attach the patch which contains the fix for this issue ?

Thanks in Advance,
Murali
Comment 20 Stefan Ring 2015-05-08 07:32:07 EDT
Created attachment 1023457 [details]
Reconstructed patch

From looking at the closest released versions before and after this patch has been added, I would expect it to be this.

Note You need to log in before you can comment on or make changes to this bug.