On 2/21/23 07:33, Laszlo Ersek wrote:
> On 2/20/23 19:21, Laszlo Ersek wrote:
>> On 2/15/23 21:57, Eric Blake wrote:
>>> On Wed, Feb 15, 2023 at 03:11:36PM +0100, Laszlo Ersek wrote:
>
>>>> +
>>>> + xwrite (STDERR_FILENO, file, strlen (file));
>>>> + xwrite (STDERR_FILENO, ":", 1);
>>>
>>> Presumably, if our first best-effort xwrite() fails to produce full
>>> output, all later xwrite() will hopefully hit the same error condition
>>> so that we aren't producing even more-mangled output where later
>>> syscalls succeed despite missing context earlier in the overall
>>> output. If it were something we truly wanted to worry about, the
>>> solution would be pre-loading the entire message into a single buffer,
>>> then calling xwrite() just once - but that's far more effort for
>>> something we don't anticipate hitting in normal usage anyways. I'm
>>> happy if you ignore this whole paragraph of mine.
>>
>> Any single buffer presents the problem of sizing the buffer
>> appropriately, which we can't do in this context :)
>
> Actually, we *can* do better:
>
>
https://pubs.opengroup.org/onlinepubs/9699919799/functions/writev.html
>
> What we're doing here is the textbook use case for scatter-gather (well,
> in this case, gather). It's strange that it has taken me one night to
> realize this (it occurred to me before falling asleep last night), given
> that I heavily used scatter-gather in other, not-so-old, code. (Namely
> the edk2 virtiofs driver.)
>
> I'll attempt to replace xwrite() with xwritev().
No, I won't -- writev() is not required to be async-signal-safe, so it's
not good enough for NBD_INTERNAL_FORK_SAFE_ASSERT().
Actually, that's a bug in POSIX; writev() is async-safe on all known
platforms:
In part because writev() is documented as being "identical to write()
except for..." where the exception does NOT mention async safety, and
therefore writev() must be async safe if write() is.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: