On Sat, Sep 19, 2020 at 7:57 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Sat, Sep 19, 2020 at 05:14:41PM -0700, Andy Lutomirski wrote: > > > > 2) have you counted the syscalls that do and do not need that? > > > > No. > > Might be illuminating... > > > > 3) how many of those realistically *can* be unified with their > > > compat counterparts? [hint: ioctl(2) cannot] > > > > There would be no requirement to unify anything. The idea is that > > we'd get rid of all the global state flags. > > _What_ global state flags? When you have separate SYSCALL_DEFINE3(ioctl...) > and COMPAT_SYSCALL_DEFINE3(ioctl...), there's no flags at all, global or > local. They only come into the play when you try to share the same function > for both, right on the top level. ... > > > For ioctl, we'd have a new file_operation: > > > > long ioctl(struct file *, unsigned int, unsigned long, enum syscall_arch); > > > > I'm not saying this is easy, but I think it's possible and the result > > would be more obviously correct than what we have now. > > No, it would not. Seriously, from time to time a bit of RTFS before grand > proposals turns out to be useful. As one example, look at __sys_setsockopt(). It's called for the native and compat versions, and it contains an in_compat_syscall() check. (This particularly check looks dubious to me, but that's another story.) If this were to be done with equivalent semantics without a separate COMPAT_DEFINE_SYSCALL and without in_compat_syscall(), there would need to be some indication as to whether this is compat or native setsockopt. There are other setsockopt implementations in the net stack with more legitimate-seeming uses of in_compat_syscall() that would need some other mechanism if in_compat_syscall() were to go away. setsockopt is (I hope!) out of scope for io_uring, but the situation isn't fundamentally different from read and write.
