On 14/11/2024 12:30 pm, Jürgen Groß wrote: > On 14.11.24 13:26, Jan Beulich wrote: >> On 13.11.2024 16:29, Jürgen Groß wrote: >>> On 13.11.24 16:20, Andrew Cooper wrote: >>>> Looking over the XenServer patchqueue: >>> >>> ... >>> >>>> These are a SIGPIPE bugfix which happen to also have a perf >>>> improvement. I cant remember if we discussed backporting them before. >>>> (Juergen/Anthony?) >>>> >>>> 42db2deb5e76: tools/libxs: Fix length check in xs_talkv() >>>> e2a93bed8b9e: tools/libxs: Rework xs_talkv() to take xsd_sockmsg >>>> within >>>> the iovec >>>> f050c03ce2ad: tools/libxs: Rationalise the definition of struct >>>> xs_handle >>>> 046efe529e82: tools/libxs: Track whether we're using a socket or file >>>> ebaeb0c64a6d: tools/libxs: Use writev()/sendmsg() instead of write() >>>> a17b6db9b007: tools/libxs: Stop playing with SIGPIPE >>> >>> I'd take these, as playing with signals behind the back of a library >>> user >>> is something which should be fixed. >> >> No question about the first and last one. Are all the intermediate ones >> necessary, though? > > I think those are needed for the last one to apply.
Yes they are needed. To avoid playing with SIGPIPE, you need to use sendmsg(, MSG_NOSIGNAL) to transmit the data, which needs to distinguish sockets and files (can't sendmsg() to a file, and must not write() to a socket (no ability to pass flags)), which in turn involves having xsd_sockmsg in iov[0]. The only one that isn't strictly necessary is "Rationalise the definition of struct xs_handle" but you'd need to edit "Track whether we're using a socket or file" to add the field to both struct xs_handles, but I included it after breaking the build by not realising there was a second definition. I suggest keeping the patch. ~Andrew
