Re: deconflicting new syscall numbers for 6.11

[Linus Torvalds]

On Thu, 4 Jul 2024 at 12:19, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Bah. I guess I'll have to walk through the patch series once again.

Ok, I went through it once. First comments:

The system call additions look really random. You don't add them to
all architectures, but the ones you *do* add them to seem positively
pointless:

 - I don't think you should introduce the system all on 32-bit
architectures, and that includes as a compat call on 64-bit.

    The VM_DROPPABLE infrastructure doesn't even exist on 32-bit, and
while that might not be technically a requirement, it does seem to
argue against doing this on 32-bit architectures. Plus nobody sane
cares.

    You didn't even enable it on 32-bit x86 in the vdso, so why did
you enable it as a syscall?

 - even 64-bit architectures don't necessarily have anything like a
vdso, eg alpha.

It looks like you randomly just picked the architectures that have a
syscall.tbl file, rather than architectures where this made sense. I
thin kyou should drop all of them except possibly arm64, s390 and
powerpc.

I'm very ambivalent about the VM_DROPPABLE code.

On one hand, it's something we've discussed many times, and I don't
hate it. On the other hand, the discussions have always been about
actually exposing it to user space as a MAP_DROPPABLE so that user
space can do caching.

In fact, I'm almost certain that *because* you didn't expose it to
mmap(), people will now then instead mis-use vgetrandom_alloc()
instead to allocate random MAP_DROPPABLE pages. That is going to be a
nightmare.

And that nightmare has to be avoided. Which in turn means that I think
vgetrandom_alloc() has to go, and you just need to expose
MAP_DROPPABLE instead that obly works for private anonymous mappings,
and make sure glibc uses that.

Because as your patch series stands now, the semantics are unacceptable.

This is a non-starter. When I see a new system call where my reaction
is not just "this should have been just a mmap()", but then
immediately followed by "Oh, and people will mis-use this as a cool
mmap", I'm not merging that system call.

So I don't hate VM_DROPPABLE per se, but the interface is simply not
ok. vgetrandom_alloc() absolutely *has* to go, and needs to just be a
user-space wrapper around regular mmap.

                 Linus