On Thu, May 18, 2023 at 10:33:30AM -0700, Linus Torvalds wrote: > On Thu, May 18, 2023 at 10:20 AM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > > That's just completely weird. We can see what Linus thinks but I think > > that's a somewhat outlandish proposal that I wouldn't support. > > I have no idea of the background here. > > But fd 0 is in absolutely no way special. Anything that thinks that a > zero fd is invalid or in any way different from (say) fd 5 is > completely and utterly buggy by definition. > > Now, fd 0 can obviously be invalid in the sense that it may not be > open, exactly the same way fd 100 may not be open. So in *that* sense > we can have an invalid fd 0, and system calls might return EBADF for > trying to access it if somebody has closed it. > > If bpf thinks that 0 is not a file descriptor, then bpf is simply > wrong. No ifs, buts or maybes about it. It's like saying "1 is not a > number". It's nonsensical garbage. > > But maybe I misunderstand the issue. TL;DR bpf has considerd fd 0 to be an invalid fd value for a long time. We can't exactly follow the motiviation: https://lore.kernel.org/bpf/CAADnVQLitLUc1SozzKjBgq6HGTchE1cO+e4j8eDgtE0zFn5VEw@xxxxxxxxxxxxxx and it's probably to late to change this. Yes, passing fds in extensible structs is inconvenient because you need to pass an indicator alongside an fd to indicate that the zero value is anactual file descriptor. Because unknown fields need to be initialzied to zero so that old kernels can ignore larger structs. So what we usually have to do: mount_setattr() attr.set |= MOUNT_ATTR_IDMAP; attr.userns_fd = 0; We just found out about fd 0 being invalid because a new bpf feature proposal now tried to reuse fd 0 to mean AT_FDCWD when passed through a new bpf feature; which I said isn't acceptable.
