Re: preparations for 4.19.1

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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