On Mon, Oct 19, 2015 at 11:53:25AM -0700, John Stultz wrote: > On Fri, Oct 9, 2015 at 1:25 AM, Jesper Nilsson <jesper.nilsson@xxxxxxxx> wrote: > > Of course, the proposed patch only allows the setting of relative > > timeouts with TFD_TIMER_CANCEL_ON_SET, any application using > > it would also need to be patched to use the relative timer > > for this solve the described problem. > > So is this not more of a workaround? Basically just allows > applications on systems that can't handle y2038 to be able to use > different interfaces to maybe allow the system to crawl onward to the > next problem? Right, any absolute timer set on the system time is a problem when it overflows. > Miroslav had a patch recently to try to keep 32bit systems from > getting into a week near y2038 to try to stave off some of these ugly > problems. While I'm not totally against such patches (Miroslav's > concern of a DoS vector is reasonable), I also want to avoid giving > folks a false sense of confidence that the problems are resolved. Not all of the problems can be resolved, but current time overflowing 32-bit time_t can be prevented in the kernel, reliably. Applications using 32-bit time_t shouldn't be expected to handle a case when it's not really Oct 20 2015, but rather Nov 26 2151, should they? That would be like implicitly opening files with O_LARGEFILE, even for applications not compiled with 64-bit off_t. The difference to the large file support is that there is only one file (the system time) and it's shared between all applications. I think as long as there is anything with 32-bit time_t running on the machine, the system time must not be allowed to overflow. If you don't like the idea of stepping the clock back one week sooner to prevent also time_t overflowing in majority of the user-space code, it could be moved closer to the actual overflow. I don't see the benefit though. Similar applies to KTIME_MAX and the kernel code. -- Miroslav Lichvar -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
