Re: [PATCH net-next v2 17/17] net: Kill MSG_SENDPAGE_NOTLAST
Willem de Bruijn <[email protected]> Tue, 20 Jun 2023 12:59:18 +0000
| Newsgroups | org.kernel.vger.dccp,dev.linux.lists.mptcp,dev.linux.lists.virtualization,org.kernel.vger.bpf,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-can,org.kernel.vger.linux-crypto,org.kernel.vger.linux-doc,org.kernel.vger.linux-hams,org.kernel.vger.linux-kernel,org.kernel.vger.linux-perf-users,org.kernel.vger.linux-rdma,org.kernel.vger.linux-sctp,org.kernel.vger.linux-wpan,org.kernel.vger.linux-x25,org.kernel.vger.netdev,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
David Howells wrote: > Willem de Bruijn <[email protected]> wrote: > > > Is it intentional to add MSG_MORE here in this patch? > > > > I do see that patch 3 removes this branch: > > Yeah. I think I may have tcp_bpf a bit wrong with regard to handling > MSG_MORE. > > How about the attached version of tcp_bpf_push()? > > I wonder if it's save to move the setting of MSG_SENDPAGE_NOPOLICY out of the > loop as I've done here. The caller holds the socket lock. > > Also, I'm not sure whether to take account of apply/apply_bytes when setting > MSG_MORE mid-message, or whether to just go on whether we've reached > sge->length yet. (I'm not sure exactly how tcp_bpf works). I'm not very familiar with it either. Instead of inferring whether MSG_MORE is safe to set, as below, sufficient to rely on the caller to pass it when appropriate? size = min(apply_bytes, sge->length). I doubt that size < apply_bytes is ever intended. And instead of this former branch if (flags & MSG_SENDPAGE_NOTLAST) msghdr.msg_flags |= MSG_MORE; update any caller to pass MSG_MORE instead of MSG_SENDPAGE_NOTLAST, if not yet done so. > msghdr.msg_flags = flags; > > /* Determine if we need to set MSG_MORE. */ > if (!(msghdr.msg_flags & MSG_MORE)) { > if (apply && size < apply_bytes) > msghdr.msg_flags |= MSG_MORE; > else if (!apply && size < sge->length && > msg->sg.start != msg->sg.end) > msghdr.msg_flags |= MSG_MORE; > }