On Wed, May 16, 2018 at 12:05:06PM -0700, Joe Stringer wrote: > > > > A few open points: > > * Currently, the lookup interface only returns either a valid socket or a > > NULL > > pointer. This means that if there is any kind of issue with the tuple, > > such > > as it provides an unsupported protocol number, or the socket can't be > > found, > > then we are unable to differentiate these cases from one another. One > > natural > > approach to improve this could be to return an ERR_PTR from the > > bpf_sk_lookup() helper. This would be more complicated but maybe it's > > worthwhile. > > This suggestion would add a lot of complexity, and there's not many > legitimately different error cases. There's: > * Unsupported socket type > * Cannot find netns > * Tuple argument is the wrong size > * Can't find socket > > If we split the helpers into protocol-specific types, the first one > would be addressed. The last one is addressed by returning NULL. It > seems like a reasonable compromise to me to return NULL also in the > middle two cases as well, and rely on the BPF writer to provide valid > arguments. > > > * No ordering is defined between sockets. If the tuple could find multiple > > sockets, then it will arbitrarily return one. It is up to the caller to > > handle this. If we wish to handle this more reliably in future, we could > > encode an ordering preference in the flags field. > > Doesn't need to be addressed with this series, there is scope for > addressing these cases when the use case arises.
Thanks for summarizing the conf call discussion. Looking forward to non-rfc patches :)
