Re: [Y2038] [GIT PULL v3 00/27] block, scsi: final compat_ioctl cleanup
Arnd, > If this version seems ok to everyone, please pull into the scsi tree. Looks good to me. Please address Ben's comment and I'll pull it in. -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [GIT PULL v2 00/27] block, scsi: final compat_ioctl cleanup
Hi Arnd! > Any suggestion for how this should be merged? I'm pretty flexible. When you post v3 I'll try to set up a branch to get an idea what conflicts we might have to deal with. And then we can take it from there. -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH] scsi: lpfc: use monotonic timestamps for statistics
Arnd, > The get_seconds() function suffers from a possible overflow in 2038 or > 2106, as well as jitter due to settimeofday or leap second updates, > and is deprecated. > > As we are interested in elapsed time only, using ktime_get_seconds() > to read the CLOCK_MONOTONIC timebase is ideal here. This also lets us > remove the hack that tries to deal with get_seconds() going slightly > backwards, which cannot happen with montonic timestamps. Applied to 4.19/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH] scsi_transport_fc: use 64-bit timestamps consistently
Arnd, > The get_seconds() helper returns an 'unsigned long' value, which can > overflow on 32-bit architectures. Since the interface we pass it into > already uses a 64-bit type, we can just use ktime_get_real_seconds() > instead. > > While we generally prefer local timestamps in CLOCK_MONOTONIC format > (ktime_get_seconds), this keeps using the CLOCK_REALTIME version in > order to maintain compatibility with existing code. Applied to 4.19/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH] aacraid: stop using deprated get_seconds()
Arnd, > get_seconds() can overflow on 32-bit architectures and is deprecated > because of that. The use in the aacraid driver has the same problem > due to a limited firmware interface, it also overflows in the year > 2106. > > This changes all calls to get_seconds() to the non-deprecated > ktime_get_real_seconds(), which unfortunately doesn't solve that > problem but gets rid of one user of the deprecated interface. Applied to 4.19/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH] scsi: arcmsr: avoid do_gettimeofday
Arnd, > The arcmsr uses its own implementation of time_to_tm(), along with > do_gettimeofday() to read the current time. While the algoritm used > here is fine in principle, it suffers from two problems: Applied to 4.16/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH] scsi: debug: remove jiffies_to_timespec
Arnd, > There is no need to go through an intermediate timespec to convert to > ktime_t when we just want a simple multiplication. This gets rid of > one of the few users of jiffies_to_timespec, which I hope to remove as > part of the y2038 cleanup. Applied to 4.16/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH 0/7] scsi: bfa: do_gettimeofday removal
Arnd,
> The bfa driver is one of the main users of do_gettimeofday(), a
> function that I'm trying to remove as part of the y2038 cleanup.
>
> The timestamps are all uses in slightly different ways, so this has
> turned into a rather longish series for doing something that should be
> simple.
>
> The last patch in the series ("scsi: bfa: use 64-bit times in
> bfa_aen_entry_s ABI") is one that needs to be reviewed very carefully,
> and it can be skipped if the maintainers prefer to leave the 32-bit
> ABI unchanged, the rest are hopefully fairly straightforward.
Applied to 4.16/scsi-queue, thanks!
Will drop #7 if something breaks.
--
Martin K. Petersen Oracle Linux Engineering
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH] fnic: Use time64_t to represent trace timestamps
>>>>> "Deepa" == Deepa Dinamani writes: Deepa> trace timestamps use struct timespec and CURRENT_TIME which are Deepa> not y2038 safe. These timestamps are only part of the trace log Deepa> on the machine and are not shared with the fnic. Replace then Deepa> with y2038 safe struct timespec64 and ktime_get_real_ts64(), Deepa> respectively. Applied to 4.10/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH] scsi: libfc: fix seconds_since_last_reset calculation
>>>>> "Arnd" == Arnd Bergmann writes: Arnd> The fc_get_host_stats() function contains a complex conversion Arnd> from jiffies to timespec to seconds. As we try to get rid of uses Arnd> of struct timespec, we can clean this up and replace it with a Arnd> simpler computation. Arnd> Simply dividing the difference in jiffies by HZ is not only much Arnd> more efficient, it also avoids a problem that causes the Arnd> seconds_since_last_reset value to be incorrect if jiffies has Arnd> overrun since the 'boot_time' value was recorded. Applied to 4.8/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH] mpt3sas: Remove usage of 'struct timeval'
>>>>> "Tina" == Tina Ruchandani writes: Tina> 'struct timeval' will have its tv_sec value overflow on 32-bit Tina> systems in year 2038 and beyond. This patch replaces the use of Tina> struct timeval for computing mpi_request.TimeStamp, and instead Tina> uses ktime_t which provides 64-bit seconds value. The timestamp Tina> computed remains unaffected (milliseconds since Unix epoch). Applied to 4.7/scsi-queue. Thank you! -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH] mpt3sas: Remove usage of 'struct timeval'
>>>>> "Tina" == Tina Ruchandani writes: Tina> 'struct timeval' will have its tv_sec value overflow on 32-bit Tina> systems in year 2038 and beyond. This patch replaces the use of Tina> struct timeval for computing mpi_request.TimeStamp, and instead Tina> uses ktime_t which provides 64-bit seconds value. The timestamp Tina> computed remains unaffected (milliseconds since Unix epoch). Broadcom folks, please review. -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH, RESEND 3] qla2xxx: Remove use of 'struct timeval'
>>>>> "Tina" == Tina Ruchandani writes: Tina, >> Applied to 4.6/scsi-queue. Tina> I am not seeing this patch in v4.6-rc3 in Linus's tree. Not sure how I messed that up. Sorry! Applied to 4.7/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [RESEND PATCH v2] scsi: gdth: replace struct timeval with ktime_get_real_seconds()
>>>>> "Alison" == Alison Schofield writes: Alison> struct timeval will overflow on 32-bit systems in y2038 and is Alison> being removed from the kernel. Replace the use of struct timeval Alison> and do_gettimeofday() with ktime_get_real_seconds() which Alison> provides a 64-bit seconds value and is y2038 safe. Applied to 4.6/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH, RESEND 3] qla2xxx: Remove use of 'struct timeval'
>>>>> "Arnd" == Arnd Bergmann writes: Arnd> struct register_host_info stores a 64-bit UTC system time Arnd> timestamp. This patch removes the use of 'struct timeval' to Arnd> obtain that timestamp as its tv_sec value will overflow on 32-bit Arnd> systems in year 2038 beyond. The patch uses Arnd> ktime_get_real_seconds() which returns a 64-bit seconds value. Applied to 4.6/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [PATCH v3] scsi: pmcraid: replace struct timeval with ktime_get_real_seconds()
>>>>> "Alison" == Alison Schofield writes: Alison> Replace the use of struct timeval and do_gettimeofday() with 64 Alison> bit ktime_get_real_seconds. Prevents 32-bit type overflow in Alison> year 2038 on 32-bit systems. Applied. -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [RESEND PATCH] [SCSI] mvumi: 64bit value for seconds_since1970
>>>>> "Tina" == Tina Ruchandani writes: Tina> struct mvumi_hs_page2 stores a "seconds_since1970" field which is Tina> of type u64. It is however, written to, using 'struct timeval' Tina> which has a 32-bit seconds field and whose value will overflow in Tina> year 2038. This patch uses ktime_get_real_seconds() instead since Tina> it provides a 64-bit seconds value, which is 2038 safe. Under normal circumstances I would like a driver owner signoff but it doesn't look like mvumi gets much attention. Applied. -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] [RESEND PATCH] mpt2sas: Remove usage of 'struct timeval'
>>>>> "Tina" == Tina Ruchandani writes: Tina, Tina> 'struct timeval' will have its tv_sec value overflow on 32-bit Tina> systems in year 2038 and beyond. This patch replaces the use of Tina> struct timeval for computing mpi_request.TimeStamp, and instead Tina> uses ktime_t which provides 64-bit seconds value. The timestamp Tina> computed remains unaffected (milliseconds since Unix epoch). We just consolidated the mpt2sas and mpt3sas drivers into one so I'm afraid your time tweaks will have to be rebased. I encourage you repost in a couple of weeks after the merge window dust settles. Thanks! -- Martin K. Petersen Oracle Linux Engineering ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
