On Wed, Feb 05, 2025 at 10:27:25AM -0600, Yan Zhai wrote: > On Wed, Feb 5, 2025 at 3:56 AM Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > Let's not invent new magic return values. > > > > But stepping back... why do we have this EINTR case at all? > > Can we always goto next_key for all map types? > > The command returns and a set of (key, value) pairs. > > It's always better to skip then get stuck in EINTR, > > since EINTR implies that the user space should retry and it > > might be successful next time. > > While here it's not the case. > > I don't see any selftests for EINTR, so I suspect it was added > > as escape path in case retry count exceeds 3 and author assumed > > that it should never happen in practice, so EINTR was expected > > to be 'never happens'. Clearly that's not the case. > > It makes more sense to me if we just goto the next key for all types. > At least for current users of generic batch lookup, arrays and > lpm_trie, I didn't notice in any case retry would help. > I opened a patch here: https://lore.kernel.org/bpf/Z6OYbS4WqQnmzi2z@debian.debian/ Yan
