On Sun, Sep 20, 2020 at 07:07:42PM +0100, Al Viro wrote: > 2) a few drivers are really fucked in head. They use different > *DATA* layouts for reads/writes, depending upon the calling process. > IOW, if you fork/exec a 32bit binary and your stdin is one of those, > reads from stdin in parent and child will yield different data layouts. > On the same struct file. > That's what Christoph worries about (/dev/sg he'd mentioned is > one of those). > > IMO we should simply have that dozen or so of pathological files > marked with FMODE_SHITTY_ABI; it's not about how they'd been opened - > it describes the userland ABI provided by those. And it's cast in stone. > > Any in_compat_syscall() in ->read()/->write() instances is an ABI > bug, plain and simple. Some are unfixable for compatibility reasons, but > any new caller like that should be a big red flag. So an IOCB_COMPAT flag would let us know whether the caller is expecting a 32-bit or 64-bit layout? And io_uring could set it based on the ctx->compat flag. > Current list of those turds: > /dev/sg (pointer-chasing, generally insane) > /sys/firmware/efi/vars/*/raw_var (fucked binary structure) > /sys/firmware/efi/vars/new_var (fucked binary structure) > /sys/firmware/efi/vars/del_var (fucked binary structure) > /dev/uhid (pointer-chasing for one obsolete command) > /dev/input/event* (timestamps) > /dev/uinput (timestamps) > /proc/bus/input/devices (fucked bitmap-to-text representation) > /sys/class/input/*/capabilities/* (fucked bitmap-to-text representation)
