On Tue, Dec 22, 2020 at 12:19 PM Jonathan Lemon <jonathan.le...@gmail.com> wrote: > > On Tue, Dec 22, 2020 at 09:42:40AM -0500, Willem de Bruijn wrote: > > On Mon, Dec 21, 2020 at 7:09 PM Jonathan Lemon <jonathan.le...@gmail.com> > > wrote: > > > > > > From: Jonathan Lemon <b...@fb.com> > > > > > > Replace sock_zerocopy_put with the generic skb_zcopy_put() > > > function. Pass 'true' as the success argument, as this > > > is identical to no change. > > > > > > Signed-off-by: Jonathan Lemon <jonathan.le...@gmail.com> > > > > uarg->zerocopy may be false if sock_zerocopy_put_abort is called from > > tcp_sendmsg_locked > > Yes, it may well be false. The original logic goes: > > sock_zerocopy_put_abort() > sock_zerocopy_put() > sock_zerocopy_callback(..., success = uarg->zerocopy) > if (success) > > The new logic is now: > > sock_zerocopy_put_abort() > sock_zerocopy_callback(..., success = true) > uarg->zerocopy = uarg->zerocopy & success > if (uarg->zerocopy) > > The success value ls latched into uarg->zerocopy, and any failure > is persistent.
Good point. It's not entirely obvious, and a bit unintuitive to pass success in an abort statement. But it works. Abort does not schedule a notification if no skb associated with the uarg was sent. And if it was, the zerocopy state will reflect the & of all those packets. On which note, if renaming the currently inconsistent name, maybe renaming to zerocopy_success is the more descriptive one, then.
