On 1/22/19 8:32 AM, Daniel P. Berrangé wrote:
>>> +++ b/hw/vfio/pci.c
>>> @@ -2581,7 +2581,7 @@ static void vfio_populate_device(VFIOPCIDevice *vdev,
>>> Error **errp)
>>> ret = ioctl(vdev->vbasedev.fd, VFIO_DEVICE_GET_IRQ_INFO, &irq_info);
>>> if (ret) {
>>> /* This can fail for an old kernel or legacy PCI dev */
>>> - trace_vfio_populate_device_get_irq_info_failure();
>>> + trace_vfio_populate_device_get_irq_info_failure(errno);
>>
>> trace_vfio_populate_device_get_irq_info_failure(strerror(errno))
>
> The caveat is that 'strerror' is not required to be thread safe,
> however, given that this is Linux only code I guess we can assume
> the glibc impl which fortunately is thread safe.If we are going to worry about thread-safety of strerror(), we have a LOT of code to scrub (we are using it rather liberally throughout the code base). > > On this point though, does anyone know of any platforms we support[1], > or are likely to support in future, where 'strerror' is *not* thread > safe ? I'm not coming up with one, and I think the problem is independent of this series (if we DO have a problem, it's a series all its own to eradicate the use of strerror() in favor of something safer, either picking strerror_l() or dealing with the glibc vs. BSD differences in strerror_r()). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
