Fix a race in pid generation that causes pids to be reused
in [Kernel]
|
Prev: [PATCH] Alternate fix for ia64 tiger_defconfig build breakage
Next: compat-wireless based on 2.6.35-rc2 pushed out
From: George Spelvin on 11 Jun 2010 14:40 > 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". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |