Re: [PATCH for-8.2 0/4] rtc devices: Avoid putting time_t in 32-bit variables

[Peter Maydell]

On Thu, 20 Jul 2023 at 16:59, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> This patchset was prompted by a couple of Coverity warnings
> (CID 1507157, 1517772) which note that in the m48t59 RTC device model
> we keep an offset in a time_t variable but then truncate it by
> passing it to qemu_get_timedate(), which currently uses an 'int'
> argument for its offset parameter.
>
> We can fix the Coverity complaint by making qemu_get_timedate()
> take a time_t; we should also correspondingly make the
> qemu_timedate_diff() function return a time_t. However this
> will only push the issue out to callers of qemu_timedate_diff()
> if they are putting the result in a 32-bit variable or doing
> 32-bit arithmetic on it.
>
> Luckily there aren't that many callers of qemu_timedate_diff()
> and most of them already use either time_t or int64_t for the
> calculations they do on its return value. The first three
> patches fix devices which weren't doing that; patch four then
> fixes the rtc.c functions. If I missed any callsites in devices
> then hopefully Coverity will point them out.
>
> This patchset is a migration compat break for the aspeed boards,
> because the offset field in aspeed_rtc is in its vmstate struct.
> We could in theory make this a compatible migration change, but
> I don't believe we care about migration compat for these boards.
>
> I've only tested this with 'make check' and 'make check-avocado',
> which probably do not exercise these RTC devices much.
>
> I've tagged this as for-8.2 because the code has been like this
> forever. We might as well give ourselves plenty of time to see
> if there's any unforeseen consequences of widening the type.

8.2 dev cycle is now open, so I plan to take these through
the arm tree, since they're mostly arm timer devices.

thanks
-- PMM