unix/dgram: reduce mbuf chain traversals in send(2) and recv(2)

[glebius]

Summary

o Use m_pkthdr.memlen from m_uiotombuf()
o Modify unp_internalize() to keep track of allocated space and memory

as well as pointer to the last buffer.

o Modify unp_addsockcred() to keep track of allocated space and memory

as well as pointer to the last buffer.

o Record the datagram len/memlen in the first (from) mbuf of the chain

in uipc_sosend_dgram() and reuse it in uipc_soreceive_dgram().

[glebius]

Note: this patch is a step towards D35303.

[markj]

sys/kern/uipc_usrreq.c

2709

Here we check *controlp != NULL but above we assume *controlp is not NULL. Can this check be dropped?

2818–2822

If control is NULL, then *clast is uninitialized and we don't update it here. Though, the caller doesn't seem to use clast anyway...

[glebius]

Rebase

[glebius]

sys/kern/uipc_usrreq.c

2709

You are right. This is true after 24df85d29a309522a4878bdf382696c7319ce898 and 579b45e203287f78cfb4a91491893b2919aa9ec4. I will commit that separately.

[glebius]

sys/kern/uipc_usrreq.c

2818–2822

Yes, this is by design. Caller supplies &clast only if it supplies control, just in case if unp_addsockcred() decides to modify the chain and delete last mbuf. If there is nothing to modify, then there is nothing to update.

[glebius]

sys/kern/uipc_usrreq.c

2709

No, this check is still required. In the beginning of SCM_RIGHTS case there is condition when we break out without calling sbcreatecontrol(). In this case we would set it to NULL and panic on next iteration.

[glebius]

sys/kern/uipc_usrreq.c

2709

Can be triggered by SCM_RIGHTS with zero descriptors.

[glebius]

sys/kern/uipc_usrreq.c

2709

Here we check *controlp != NULL but above we assume *controlp is not NULL. Can this check be dropped?

You are right. This is true after 24df85d29a309522a4878bdf382696c7319ce898 and 579b45e203287f78cfb4a91491893b2919aa9ec4. I will commit that separately.

No, this check is still required. In the beginning of SCM_RIGHTS case there is condition when we break out without calling sbcreatecontrol(). In this case we would set it to NULL and panic on next iteration.

Okay. One week ago I fell into the same wrong conclusion as you did, that *controlp != NULL is not needed. I quickly committed that (actually smashed into other useful commit) and continued putting changes on top of that. And then spent extra hours trying to figure out why unix_passfd:empty_rights started to panic. So, I decided to rewrite this cycle, so a third person won't fall into the same confusion: D35375

[markj]

sys/kern/uipc_usrreq.c

2709

Ok, I will wait until this is rebased on D35375 before looking further.

[glebius]

Rebase on top of D35375

[glebius]

Fix bug