Re: xnanosleep range with 64 bit time_t
On Wed, Aug 30, 2006 at 10:13:52PM -0700, Paul Eggert wrote: Frank v Waveren [EMAIL PROTECTED] writes: Thomas Gleixner has submitted a replacing patch that instead just limits the timespec passed to the maximum, so that would make this patch unnecessary for linux (at least for those with new kernels). Sorry, no, that's worse. With the current Linux behavior, I can detect the bug and work around it at 'configure' time using AC_RUN_IFELSE. The same is true for a change to the kernel that would return EOVERFLOW for long sleeps; this behavior is worse, in my opinion, since it will cause more work in the application to work around, but the bug is still easily detectable at configure-time. Yes, at first I agreed with you on that, but he gave the fairly solid argument that it turned behaviour back to the (broken) way it was before ktime was introduced. How about if you just fix nanosleep so that it works in general? Surely nanosleep can just have a little loop like this: unsigned int eons = t.tv_sec 31; for (i = 0; i eons; i++) sleep for 2**31 seconds; t.tv_sec = 0x7FFF; Yeah, I was being lazy. There seems to be a little trouble with the sleep-as-long-as-we-can patch anyway, I'll see if this isn't too tricky to hack up and try submitting it. -- Frank v Waveren Key fingerprint: BDD7 D61E [EMAIL PROTECTED] 5D39 CF05 4BFC F57A Public key: hkp://wwwkeys.pgp.net/468D62C8 FA00 7D51 468D 62C8 signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: xnanosleep range with 32 bit time_t
On Thu, Aug 31, 2006 at 12:33:41AM -0700, Paul Eggert wrote: Can you please report this bug to whoever's responsible for getting nanosleep to work in the Linux kernel, if the bug isn't already fixed in more bleeding-edge versions? Works for me (i.e. returns 0) on a stock 2.6.17, but if you could keep an eye on it once the kernel in debian has reached something like 2.6.17 that would probably be prudent, just to make sure it's not something introduced by the debian patches. I'd test it on a stock 2.6.8 but I don't have one handy and the interaction between user-mode-linux host and guest nanosleep is a bit too muddy for me to trust it for testing this. -- Frank v Waveren Key fingerprint: BDD7 D61E [EMAIL PROTECTED] 5D39 CF05 4BFC F57A Public key: hkp://wwwkeys.pgp.net/468D62C8 FA00 7D51 468D 62C8 signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: xnanosleep range with 64 bit time_t
On Sat, Sep 02, 2006 at 02:14:13PM -0700, Paul Eggert wrote: Yeah, I was being lazy. There seems to be a little trouble with the sleep-as-long-as-we-can patch anyway, I'll see if this isn't too tricky to hack up and try submitting it. Thanks. Please let us know how it turns out; if nanosleep can fail with EOVERFLOW we'll have to recode things again to work around that problem. (I hope it doesn't come to that) Hmm, they've fixed the problem the the capping-the-sleep-time patch, and Thomas Gleixner doesn't seem very eager to accept the patch (not big on solutions to academic problems apparantly). I'll CC you on the thread, but suspect you're best of just waiting a little and seeing what ends up in Linus's tree. -- Frank v Waveren Key fingerprint: BDD7 D61E [EMAIL PROTECTED] 5D39 CF05 4BFC F57A Public key: hkp://wwwkeys.pgp.net/468D62C8 FA00 7D51 468D 62C8 signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: xnanosleep range with 64 bit time_t
On Sun, Aug 27, 2006 at 11:43:30AM +0200, Frank v Waveren wrote: lib/xnanosleep.c currently assumes nanosleep works with any value that can be fit into the struct timespec. For gnu+linux on a platform with 64 bit longs, this isn't true (it currently doesn't even return and error but just silently integer-overflows, but I've submitted a patch to make it error). Thomas Gleixner has submitted a replacing patch that instead just limits the timespec passed to the maximum, so that would make this patch unnecessary for linux (at least for those with new kernels). I think I prefer my solution of having it error, but even if his patch gets accepted into 2.6.18, that still leaves everyone with an older kernel, and solaris users (and given that I only checked linux and solaris, other OSes are likely to have th same problem), so I still think this patch to xnanosleep is worthwhile. -- Frank v Waveren Key fingerprint: BDD7 D61E [EMAIL PROTECTED] 5D39 CF05 4BFC F57A Public key: hkp://wwwkeys.pgp.net/468D62C8 FA00 7D51 468D 62C8 signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: xnanosleep range with 64 bit time_t
On Sun, Aug 27, 2006 at 11:04:23PM -0700, Paul Eggert wrote: Frank v Waveren [EMAIL PROTECTED] writes: I haven't checked how other operating systems handle this (do any others even have 64 bit time_t's?) Yes, pretty much every operating system with 64-bit long has 64-bit time_t, which means most OSes these days (at least on some platform). So we can't install that patch as-is: it would break things on too many platforms. After mailing the above, I went and had a look at a solaris machine. Guess what? 0.0354 getrlimit(RLIMIT_STACK, 0x7448) = 0 0.0355 getcontext(0x7160) 0.0358 context(3, 0x7F0C4EE0) 0.0360 sysconfig(_CONFIG_SEM_VALUE_MAX)= 2147483647 0.0363 nanosleep(0x7AD0, 0x) = 0 0.0366 _exit(4294969536) It does the same thing. lib/xnanosleep.c currently assumes nanosleep works with any value that can be fit into the struct timespec. For gnu+linux on a platform with 64 bit longs, this isn't true (it currently doesn't even return and error but just silently integer-overflows, but I've submitted a patch to make it error). That doesn't sound right. Why not just fix nanosleep so that it works instead? It shouldn't be that hard. There shouldn't be an arbitrary upper bound to the length of the sleep. I agree that would be a pleasing solution, but since it'll stop the number of nanoseconds in the sleep from being exressible as a single integer it's going to make a lot of code very unpleasant, and it's certainly no small undertaking. Also, until the kernel bug gets fixed, what's the harm of leaving coreutils alone? The bug occurs only for sleeps longer than about 68 years, so it's not like this is a burning issue. This turns a perfectly reasonable while sleep inf; do done to sleep forever from a slightly unpleasant piece of idiom into a busy wait. I'd say that's worth fixing. -- Frank v Waveren Key fingerprint: BDD7 D61E [EMAIL PROTECTED] 5D39 CF05 4BFC F57A Public key: hkp://wwwkeys.pgp.net/468D62C8 FA00 7D51 468D 62C8 signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
xnanosleep range with 64 bit time_t
lib/xnanosleep.c currently assumes nanosleep works with any value that can be fit into the struct timespec. For gnu+linux on a platform with 64 bit longs, this isn't true (it currently doesn't even return and error but just silently integer-overflows, but I've submitted a patch to make it error). I haven't checked how other operating systems handle this (do any others even have 64 bit time_t's?), but the follow patch stops it from failing silently on linux, and if and when my patch is accepted, it stops it from erroring. If there are other operating systems the coreutils run on that handle 64 bit time_t's properly this should be #ifdef linux-ed, but I'll leave that to someone who knows more about the build system. --- coreutils/lib/xnanosleep.c.old 2006-08-27 10:49:11.0 +0200 +++ coreutils/lib/xnanosleep.c 2006-08-27 11:40:25.0 +0200 @@ -34,9 +34,10 @@ #include intprops.h #include timespec.h +#include minmax.h #ifndef TIME_T_MAX -# define TIME_T_MAX TYPE_MAXIMUM (time_t) +# define TIME_T_MAX MIN(TYPE_MAXIMUM (time_t), (~(131))) #endif /* Sleep until the time (call it WAKE_UP_TIME) specified as -- Frank v Waveren Key fingerprint: BDD7 D61E [EMAIL PROTECTED] 5D39 CF05 4BFC F57A Public key: hkp://wwwkeys.pgp.net/468D62C8 FA00 7D51 468D 62C8 signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: xnanosleep range with 64 bit time_t
I should add this patch is against current CVS. xnanosleep.c hasn't changed much recently, but minmax.h is new. -- Frank v Waveren Key fingerprint: BDD7 D61E [EMAIL PROTECTED] 5D39 CF05 4BFC F57A Public key: hkp://wwwkeys.pgp.net/468D62C8 FA00 7D51 468D 62C8 signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
