On Thu, 20 Jul 2023 at 16:59, Peter Maydell <peter.mayd...@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
