On Tue, 29 Sep 2026 14:57:54 +0100 Bruce Richardson <[email protected]> wrote:
> On Tue, Sep 29, 2026 at 06:42:08AM -0700, Stephen Hemminger wrote: > > On Tue, 29 Sep 2026 09:39:36 +0100 > > Bruce Richardson <[email protected]> wrote: > > > > > On Mon, Sep 28, 2026 at 04:15:58PM -0700, Stephen Hemminger wrote: > > > > Many parts of DPDK will fail with divide by zero and > > > > other errors if the initialization logic ever TSC hz was ever > > > > determined to be zero. This might happen on a broken get_tsc_freq_arch() > > > > or bad emulation in QEMU. > > > > > > > > If TSC hz is zero, log the error and propagate back to > > > > fail rte_eal_init(). > > > > > > > > This fix doesn't need to go to stable since it is a purely > > > > theoretical problem; we aren't getting divide by zero reports > > > > from users. > > > > > > > > > > How was this discovered? Is there a coverity issue id, or was it just AI > > > discovered? > > > > It was part of review of pcapng timestamp calculation. > > Kind of funny, AI spotted overflow (which I verified) in the code which > > it had previously helped write. Then it was asking it self, > > "what if TSC was 0". I didn't see how this could happen unless QEMU > > had some broken CPU emulation. > > > > To me it seemed best to fail fast and die in a safer manner. > > > Agreed. You can add my ack, either for this version or a new version with > the "set" function renamed as I suggest. > > Acked-by: Bruce Richardson <[email protected]> > I also updated comment to rte_get_tsc_hz() since existing comment implies the value could be different on each lcore.
