Re: [PATCH 0/6] tools/libxs: Fix SIGPIPE handling issues

[Jan Beulich <jbeulich@xxxxxxxx>]

On 18.07.2024 18:48, Andrew Cooper wrote:
> While the purpose of this series is patch 6, it has a side effect of reducing
> the number of system calls substantally.
> 
> Using a strace of test-xenstore as an example, we go from this:
> 
>   rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[], 
> sa_flags=SA_RESTORER, sa_restorer=0x7fda8278e2f0}, {sa_handler=SIG_DFL, 
> sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fda8278e2f0}, 8) = 0
>   write(3, "\v\0\0\0\0\0\0\0\0\0\0\0\30\0\0\0", 16) = 16
>   write(3, "xenstore-test/502673/a\0", 23) = 23
>   write(3, "a", 1)                        = 1
>   read(3, "\v\0\0\0\0\0\0\0\0\0\0\0\3\0\0\0", 16) = 16
>   read(3, "OK\0", 3)                      = 3
>   rt_sigaction(SIGPIPE, {sa_handler=SIG_DFL, sa_mask=[], 
> sa_flags=SA_RESTORER, sa_restorer=0x7fda8278e2f0}, NULL, 8) = 0
> 
> down to this:
> 
>   sendmsg(3, {msg_name=NULL, msg_namelen=0, 
> msg_iov=[{iov_base="\v\0\0\0\0\0\0\0\0\0\0\0\30\0\0\0", iov_len=16}, 
> {iov_base="xenstore-test/504021/a\0", iov_len=23}, {iov_base="a", 
> iov_len=1}], msg_iovlen=3, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 40
>   read(3, "\v\0\0\0\0\0\0\0\0\0\0\0\3\0\0\0", 16) = 16
>   read(3, "OK\0", 3)                      = 3
> 
> 
> I.e., it removes 2x rt_sigaction(), and turns all write()'s into a single
> writev() or sendmsg().
> 
> 
> Reads are a little more problematic to deal with.  Xenstored will produce a
> full package basically in one go, but libxenstore's reading is horrbly
> complicated by virtue of it being completely different depending on whether
> xs_watch() has created a secondary read thread or not.
> 
> Andrew Cooper (6):
>   tools/libxs: Fix length check in xs_talkv()
>   tools/libxs: Rework xs_talkv() to take xsd_sockmsg within the iovec
>   tools/libxs: Rationalise the definition of struct xs_handle
>   tools/libxs: Track whether we're using a socket or file
>   tools/libxs: Use writev()/sendmsg() instead of write()
>   tools/libxs: Stop playing with SIGPIPE

The title of the entire series containing "Fix" vs there being no single
Fixes: tag throughout, afaics, leave unclear to me whether any or all of
this work wants/needs backporting. Please clarify.

Jan