Right. I've realized that after sending that email two days ago. Now bpf-next->net-next PR is pending and as soon as it's merged bpf-next will have all the recent bits.
You realise that one of the SCTP getsockopt() is actually a command! It is one of the requests that changes state and should probably have been a separate system call. David - Registered Address Lake
No. Only setsockopt can be fed kernel addresses from bpf-cgroup. There is no point in complicating the read side interface when it doesn't have that problem.
Another 'gotcha' ... On an least some architectures (possibly only m68k) IIRC all structures are actually passed by reference. (This used to be true for sparc - but it may have changed in the last 30
Are you planning to make the equivalent change to getsockopt()? Having mismatched interfaces would be very strange. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1
could you rebase on bpf-next tree and we can route it this way then? we'll also test the whole thing before applying. sounds like v2 is needed anyway to address Eric's addr space concern?
Hi Dave, setsockopt is the last place in architecture-independ code that still uses set_fs to force the uaccess routines to operate on kernel pointers. This series adds a new sockptr_t type that can