On Sun, Sep 06, 2026 at 04:02:47AM +0000, [email protected] wrote: > - [High] This problem wasn't introduced by this patch, but state > desynchronization when reprinting a previously failed trace entry causes > the current entry in the ring buffer to be incorrectly consumed and > permanently dropped.
print_graph_entry() does not always return TRACE_TYPE_HANDLED. print_graph_entry_nested() returns TRACE_TYPE_NO_CONSUME, for the reason given in the comment above it, so the quoted branch is not reached in the nested case. For a leaf, print_graph_entry_leaf() has printed the entry and its return as one line, so the entry left at the head has already been shown and consuming it is correct, as it is on the normal path. The iter->cpu != cpu test is what separates the two: on another CPU the head is not the return of the pair just reprinted, so it is left alone and ignore is set for it instead. The other two are pre-existing, and I looked at both while working on this patch. get_return_for_leaf() returning at !event has already consumed the entry, so failing there leaves data->failed set over a copy from an earlier pass. I saw that once in about 30000 replays but could not pin any output on it, so I have not sent a fix; say the word if you would rather have one on the reachability argument alone. The static on ret in print_graph_entry() has no reason to be there, though I found nothing that misbehaves. Thanks, Donggeun
