On Tue, Jul 30, 2024 at 01:15:52AM GMT, viro@xxxxxxxxxx wrote: > From: Al Viro <viro@xxxxxxxxxxxxxxxxxx> > > I strongly suspect that 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. > > If that's true, we should get the same benefits from straight > fdget()/fdput(). And AFAICS 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. > > We could split that commit in two (getting rid of sockd_lookup_light() > and switch to CLASS(fd, ...)), but AFAICS it ends up being harder to read > that way. > > [conflicts in a couple of functions] > > Signed-off-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx> > --- Reviewed-by: Christian Brauner <brauner@xxxxxxxxxx>
