epoll_wait.2: Describe timeout limitation in kernels < 2.6.37

As reported by Fredrik (and as far as I can tell the problem
went back to 2.6.0):

The timeout argument has an upper limit. Any values above that
limit are treated the same as -1, i.e. to wait indefinitely.
The limit is given by:

    #define EP_MAX_MSTIMEO min(1000ULL * MAX_SCHEDULE_TIMEOUT / HZ, \
	(LONG_MAX - 999ULL) / HZ)

That is, the limit depends on the size of a long and the timer
frequency.  Assuming the a long is never smaller than 32 bits
and HZ never larger than 1000, the worst case is 35 minutes.
I think this should be mentioned under "BUGS".

Although this is likely to be fixed in the future
(http://lkml.org/lkml/2010/8/8/144), the problem exists in
at least 2.6.14 - 2.6.35. I don't know if select(2) and poll(2)
are affected.

https://bugzilla.kernel.org/show_bug.cgi?id=20762

Reported-by: Fredrik Arnerup <arnerup@kth.se>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

man2/epoll_wait.2

@@ -20,7 +20,7 @@
 .\"
 .\" 2007-04-30: mtk, Added description of epoll_pwait()
 .\"
-.TH EPOLL_WAIT 2 2012-05-02 "Linux" "Linux Programmer's Manual"
+.TH EPOLL_WAIT 2 2012-08-16 "Linux" "Linux Programmer's Manual"
 .SH NAME
 epoll_wait, epoll_pwait \- wait for an I/O event on an epoll file descriptor
 .SH SYNOPSIS
@@ -198,6 +198,18 @@ If the new file descriptor becomes ready,
 it will cause the
 .BR epoll_wait ()
 call to unblock.
+.SH BUGS
+In kernels before 2.6.37, a
+.I timeout
+value larger than approximately
+.I LONG_MAX / HZ
+milliseconds is treated as \-1 (i.e., infinity).
+Thus, for example, on a system where the
+.I sizeof(long)
+is 4 and the kernel
+.I HZ
+value is 1000,
+this means that timeouts greater than 35.79 minutes are treated as infinity.
 .SH "SEE ALSO"
 .BR epoll_create (2),
 .BR epoll_ctl (2),