> > > Because maps can be called from userspace and kernel code, this function > > > can have a scenario where the next_key was found but by the time we > > > try to retrieve the value the element is not there, in this case the > > > function continues and tries to get a new next_key value, skipping the > > > deleted key. If at some point the function find itself trap in a loop, > > > it will return -EINTR. > > > > Good to point this out! I don't think that unbounded continue; > > statements until an interrupt happens is sufficient. Please bound the > > number of retries to a low number. > > And what would it be a good number? Maybe 3 attempts? 3 sounds good to me. > And in that case what error should be reported? One that's unambiguous and somewhat intuitive for the given issue. Perhaps EBUSY? > > > The function will try to fit as much as possible in the buf provided and > > > will return -EINVAL if buf_len is smaller than elem_size. > > > > > > QUEUE and STACK maps are not supported. > > > > > > Note that map_dump doesn't guarantee that reading the entire table is > > > consistent since this function is always racing with kernel and user code > > > but the same behaviour is found when the entire table is walked using > > > the current interfaces: map_get_next_key + map_lookup_elem. > > > > > It is also important to note that with a locked map, the lock is grabbed > > > for 1 entry at the time, meaning that the returned buf might or might not > > > be consistent. > > > > Would it be informative to signal to the caller if the read was > > complete and consistent (because the entire table was read while the > > lock was held)? > > Mmm.. not sure how we could signal that to the caller. But I don't > think there's a way to know it was consistent Okay, that makes for a simple answer :) No need to try to add a signal, then.
