On Sun, May 17, 2026 at 4:15 PM Stephen Hemminger <[email protected]> wrote: > > Warning: (unchanged from v1) gve_read_clock and the periodic > gve_read_nic_clock alarm callback both issue > GVE_ADMINQ_REPORT_NIC_TIMESTAMP into the single shared DMA buffer > priv->nic_ts_report, then read it after gve_adminq_execute_cmd > has released adminq_lock. If gve_read_clock is preempted between > gve_adminq_report_nic_timestamp returning and the be64_to_cpu > read, the alarm callback can memset() and reissue its own > command, so the user thread will read either zero or another > command's response. The simplest fix is for gve_read_clock to > return the cached priv->last_read_nic_timestamp instead of > issuing a fresh adminq command - the 250ms periodic sync keeps > it fresh enough for .read_clock semantics. Once the dev_op > registration is restored this race becomes reachable.
I want to make sure I fully understand the API contract here. Is the fact that .read_clock does not require a fresh device read documented in the DPDK specification, or is this based on typical application use cases? If the latter, what are those typical use cases?
