Re: [PATCH] Fix a race in pid generation that causes pids to be reused

["George Spelvin" <linux@horizon.com>]

> Isn't: return a - base < b - base, the natural way to express this?

Quite right.

I see people managed to figure it out, but my, what a lot of angst
over something so familiar to any network hacker trying to figure out
if a received sequence number is in the receive window or not.

See include/net/tcp.h:
265: /* is s2<=s1<=s3 ? */
266: static inline int between(__u32 seq1, __u32 seq2, __u32 seq3)
267: {
268: 	return seq3 - seq2 >= seq1 - seq2;
269: }

(If someone wants to fix the far uglier version in net/tipc/link.h...
Allan, Cc: to you.)

If you want to handle strictly conforming ANSI C, then you have to
cast everything to unsigned before the subtraction, but in practice,
casting afterward works just as well:

	return (unsigned)a - (unsigned)base < (unsigned)b - (unsigned)base;
	return (unsigned)(a - base) < (unsigned)(b - base)

Conceptually, it's "is the distance forward from base to a less than
the distance forward from base to b"?  The "forward" is enforced by the
unsigned cast.

If the numbers wrap before UINT_MAX, the logic still works; it doesn't
care if values between PID_MAX_LIMIT and UINT_MAX are "illegal and may not
be assigned" or "by merest chance happen to not be assigned".