Re: [PATCH v3 01/28] net/socket.c: switch to CLASS(fd)
From: Simon Horman <horms@kernel.org>
Date: 2024-11-02 12:21:42
Also in:
cgroups, kvm, linux-fsdevel
On Sat, Nov 02, 2024 at 05:07:59AM +0000, Al Viro wrote:
The important part in sockfd_lookup_light() is avoiding needless file refcount operations, not the marginal reduction of the register pressure from not keeping a struct file pointer in the caller. Switch to use fdget()/fdpu(); with sane use of CLASS(fd) we can get a better code generation... Would be nice if somebody tested it on networking test suites (including benchmarks)... sockfd_lookup_light() does fdget(), uses sock_from_file() to get the associated socket and returns the struct socket reference to the caller, along with "do we need to fput()" flag. No matching fdput(), the caller does its equivalent manually, using the fact that sock->file points to the struct file the socket has come from. Get rid of that - have the callers do fdget()/fdput() and use sock_from_file() directly. That kills sockfd_lookup_light() and fput_light() (no users left). What's more, we can get rid of explicit fdget()/fdput() by switching to CLASS(fd, ...) - code generation does not suffer, since now fdput() inserted on "descriptor is not opened" failure exit is recognized to be a no-op by compiler. Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
...
quoted hunk ↗ jump to hunk
diff --git a/net/socket.c b/net/socket.c
...
quoted hunk ↗ jump to hunk
@@ -2926,16 +2900,18 @@ static int do_recvmmsg(int fd, struct mmsghdr __user *mmsg, datagrams = 0; - sock = sockfd_lookup_light(fd, &err, &fput_needed); - if (!sock) - return err; + CLASS(fd, f)(fd); + + if (fd_empty(f)) + return -EBADF; + sock = sock_from_file(fd_file(f)); + if (unlikely(!sock)) + return -ENOTSOCK;
Hi Al, There is an unconditional check on err down on line 2977. However, with the above change err is now only conditionally set before we reach that line. Are you sure that it will always be initialised by the time line 2977 is reached? ...