Re: [PATCH 2/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
David Laight <[email protected]>
| Newsgroups | org.kernel.vger.linux-api,dev.linux.lists.patches,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.netdev,org.kvack.linux-mm |
|---|---|
| Message-ID | <20260604183829.63c35fd9@pumpkin> |
On Thu, 4 Jun 2026 07:17:10 -0700 Linus Torvalds <[email protected]> wrote: > On Thu, 4 Jun 2026 at 02:06, David Laight <[email protected]> wrote: > > > > Something needs to ensure that the high 32bits of the fd get masked off > > on 64bit systems. > > That something already exists: CLASS(fd, f)(fd); > > It ignores the top bits, because 'fdget()' takes an 'unsigned int'. > > We have been a bit random in how we declare the system calls in > general, and we mix 'unsigned int' and 'int' and 'unsigned long' > pretty much randomly when it comes to file descriptor arguments to > system calls. > > fs/read_write.c in particular uses all three cases with no real logic to it all: > > SYSCALL_DEFINE3(lseek, unsigned int, fd, .. > SYSCALL_DEFINE3(readv, unsigned long, fd, .. > SYSCALL_DEFINE4(sendfile, int, out_fd, .. > > but then anything that uses fdget() (through one of the helper classes > or not) will simply not care. > > Does it make sense? Is it pretty? Nope. Does it matter? Also nope. I know it has mattered elsewhere, and is easy to get wrong because 'mostly it works'. At least u32/u64 is reasonably sane - the called function has to ignore the high bits (at least on x86). Bool is another matter entirely, (IIRC from a couple of weeks ago) gcc will assume that the low 8 bits of the parameter register are either 0 or 1 and clang assumes that the low 32 bits are 0 or 1. You can't even check with 'if ((u32)bool_param > 1) error()' because the compiler 'knows' it can't be false. It all dumps you down one of the UB 'rabbit holes'. -- David > > Linus