diff --git a/man2/getrlimit.2 b/man2/getrlimit.2
index 8225e143c..e708a948e 100644
--- a/man2/getrlimit.2
+++ b/man2/getrlimit.2
@@ -61,7 +61,7 @@
 .\" 2008-05-07, mtk / Peter Zijlstra, Added description of RLIMIT_RTTIME
 .\" 2010-11-06, mtk: Added documentation of prlimit()
 .\"
-.TH GETRLIMIT 2 2012-11-24 "Linux" "Linux Programmer's Manual"
+.TH GETRLIMIT 2 2012-11-25 "Linux" "Linux Programmer's Manual"
 .SH NAME
 getrlimit, setrlimit, prlimit \- get/set resource limits
 .SH SYNOPSIS
@@ -614,6 +614,33 @@ was calculated as
 This was fixed in kernel 2.6.13.
 .\" see http://marc.theaimsgroup.com/?l=linux-kernel&m=112256338703880&w=2
 
+Since Linux 2.6.12,
+.\" The relevant patch, sent to LKML, seems to be
+.\" http://thread.gmane.org/gmane.linux.kernel/273462
+.\" From: Roland McGrath <roland <at> redhat.com>
+.\" Subject: [PATCH 7/7] make RLIMIT_CPU/SIGXCPU per-process
+.\" Date: 2005-01-23 23:27:46 GMT
+if a process reaches its soft
+.BR RLIMIT_CPU
+limit and has a handler installed for
+.BR SIGXCPU ,
+then, in addition to invoking the signal handler,
+the kernel increases the soft limit by one second.
+This behavior repeats if the process continues to consume CPU time,
+until the hard limit is reached,
+at which point the process is killed.
+Other implementations
+.\" Tested Solaris 10, FreeBSD 9, OpenBSD 5.0
+do not change the
+.BR RLIMIT_CPU
+soft limit in this manner,
+and the Linux behavior is probably not standards conformant;
+portable applications should avoid relying on this Linux-specific behavior.
+.\" FIXME https://bugzilla.kernel.org/show_bug.cgi?id=50951
+The Linux-specific
+.BR RLIMIT_RTTIME
+limit exhibits the same behavior when the soft limit is encountered.
+
 Kernels before 2.4.22 did not diagnose the error
 .B EINVAL
 for