Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 9 Aug 2023 08:48:11 -0700 | Subject | Re: [PATCH RFC] Introduce uniptr_t as a generic "universal" pointer |
| |
On Wed, 9 Aug 2023 at 07:38, Christoph Hellwig <hch@lst.de> wrote: > > The original set_fs removal series did that as uptr_t, and Linus > hated it with passion. I somehow doubt he's going to like it more now.
Christoph is right. I do hate this. The whole "pass a pointer that is either user or kernel" concept is wrong.
Now, if it was some kind of extended pointer that also included the length of the area and had a way to deal with updating the pointer sanely, maybe that would be a different thing.
And it should guarantee that in the case of a user pointer it had gone through access_ok().
And it also allowed the other common cases like having a raw page array, along with a unified interface to copy and update this kind of pointer either as a source or a destination, that would be a different thing.
But this kind of "if (uniptr_is_kernel(src))" special case thing is just garbage and *not* acceptable.
And oh, btw, we already *have* that extended kind of unipointer thing.
It's called "struct iov_iter".
And yes, it's a very complicated thing, exactly because it handles way more cases than that uniptr_t. It's a *real* unified pointer of many different types.
Those iov_iter things are often so complicated that you really don't want to use them, but if you really want a uniptr, that is what you should do. It comes with a real cost, but it does come with real advantages, one of which is "this is extensively tested nfrastructure".
Linus
| |