Thread (10 messages) 10 messages, 4 authors, 2026-02-02

Re: [PATCH net-next RFC 0/3] net: move .getsockopt away from __user buffers

From: Jens Axboe <axboe@kernel.dk>
Date: 2026-01-31 15:53:58
Also in: bpf, io-uring, lkml

On 1/31/26 8:37 AM, David Laight wrote:
On Fri, 30 Jan 2026 17:19:55 -0800
Linus Torvalds [off-list ref] wrote:
quoted
On Fri, 30 Jan 2026 at 14:40, David Laight [off-list ref] wrote:
quoted
There is not much point making the 'optval' parameter more than
a structure of a user and kernel address - one of which will be NULL.  
That's exactly what we do *NOT* want. Because people will get it
wrong, and then we're back to the bad old days where trivial bugs
result in security issues.
It can still be a (semi-)transparent structure that code isn't allowed
to change. That is no different from using iov_iter.
Then why not just use iov_iter?! FWIW, I fully agree with Linus on this
one. We have an existing abstraction, we should use it. We've previously
optimized common cases, like ITER_UBUF, if that ended up being
important. We're better off using iov_iter and improving that, rather
than some new mixed pointer abomination.
quoted
Can you point to an actual case where setsockopt / getsockopt would be
performance-critical? Typically you do it once or twice.
IIRC a really horrid one - I think for async io.
That is also one of the few where the supplied length is a lie.
Huh?

-- 
Jens Axboe
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help