On Friday 30 October 2015 01:54:10 Tina Ruchandani wrote:
Thanks for the conversion. Can you please check if other (scsi) drivers have the same y2038 issues? A quick "git grep do_gettimeofday drivers/scsi/ | wc -l" reveals 30 occurrences (of cause not all are problematic).
In fact all of them are problematic, just for different reasons.
* Some drivers actually overflow in 2038 in a way that causes problems in those drivers. These obviously need to be fixed right away.
* A second class of drivers pass time_t/timeval/timespec values to or from user space. Even in cases where the absolute numbers are small (monotonic times, or time intervals), we have to change them to be able to deal with 32-bit user space that will be compiled against a modified libc using 64-bit time_t.
* All other driver are likely not broken, but we want to change them anyway, to annotate the fact that we have looked at them. My goal is to remove the definition of time_t (and all derived structures) from the kernel once all drivers have been converted, to ensure that we are not adding new broken users, and to have a reasonable confidence that we have in actually found the ones that were wrong.
Hi Johannes, Yes, there are quite a few occurrences of timeval within scsi. I had sent some of the trivial back in the Feb-May 2015 period, and they were ack-ed by my then mentor and a couple of other people, but not merged or ack-ed by someone from linux-scsi. Until today, I thought using "RESEND" would be impolite, but now I will resend the other ones as well. Arnd Bergmann is leading this effort and may have more insightful comments.
I provided a "Reviewed-by" tag in https://lkml.org/lkml/2015/5/5/201 . Normally, when patches get picked up directly from the list, the person who merges it should add the tags directly.
However, if you have to re-send the patch (with or without small modifications), you should add that tag after your Signed-off-by, so it does not get lost when the new patch is applied.
Arnd