[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 3/4] trace: forbid use of %m in trace event f

From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v2 3/4] trace: forbid use of %m in trace event format strings
Date: Tue, 22 Jan 2019 11:19:42 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

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

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]