Messages in this thread | | | Date | Sun, 29 Nov 1998 14:48:32 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: [tiny patch] Timeout overflow in select() |
| |
On Sat, 28 Nov 1998, Stephane Belmon wrote:
>the limit (well, without testing :-) ). If it was woken up after a couple >hours, it could easily recover: just check the current time - in most >cases it will do that anyway. The "-1" in my patch makes _really_ sure we >have no collision with "eternity" (in case someone changes the definition >of MAX_SELECT_SECOND). Linus?
I understand your point but remember that we are talking about 497 day of delay that will be exchanged with "eternity". Arch that uses HZ > 100 has a 64bit jiffies.
>Andrea, here are some comments on your original patch, for the record:
Thanks.
>like that. It's not the upper bound on the timeout. "Eternity" is a >special case. It's probably better to leave it clearly separated from the >range of valid values. The same way open() returns -1 on error: -1 is not >a valid FD (which is, in realistic settings, an unsigned short). Same >trick for getchar(). The rest depends on the exact semantics you want for >select(), as I explained above.
Personally I see more safe to stall forever than returning before the expected time. This is always been my feeling as you can see from schedule_timeout().
>One more comment on your patch: Generally speaking, this style of checking >overflows _after_ they happen makes me a little nervous. It works in many >cases, like what you do: "a+b". If you're doing "a+b+c", testing things >like the sign of the result doesn't catch all overflows; nor if you have >multiplications. So a seemingly innocent change made later on could break >the test: a case of bad "bug locality".
I can add a comment but I don' t care too much about this issue. Following this thought we should not write kernel code at all ;). Everything can be screwed up by a mistake from somebody like me ;>>.
Andrea Arcangeli
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |