On Tue, Mar 10, 2020 at 05:47:06PM +0000, Lorenz Bauer wrote: > We want to use sockhash and sockmap to build the control plane for > our upcoming BPF socket dispatch work. We realised that it's > difficult to resize or otherwise rebuild these maps if needed, > because there is no way to get at their contents. This patch set > allows a privileged user to retrieve fds from these map types, > which removes this obstacle. > > The approach here is different than that of program arrays and > nested maps, which return an ID that can be turned into an fd > using the BPF_*_GET_FD_BY_ID syscall. Sockets have IDs in the > form of cookies, however there seems to be no way to go from > a socket cookie to struct socket or struct file. Hence we > return an fd directly. we do store the socket FD into a sockmap, but returning new FD to that socket feels weird. The user space suppose to hold those sockets. If it was bpf prog that stored a socket then what does user space want to do with that foreign socket? It likely belongs to some other process. Stealing it from other process doesn't feel right. Sounds like the use case is to take sockets one by one from one map, allocate another map and store them there? The whole process has plenty of races. I think it's better to tackle the problem from resize perspective. imo making it something like sk_local_storage (which is already resizable pseudo map of sockets) is a better way forward.
