[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
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
- Re: [Qemu-devel] [PATCH v2 1/4] display: ensure qxl log_buf is a nul terminated string, (continued)
[Qemu-devel] [PATCH v2 4/4] trace: add ability to do simple printf logging via systemtap, Daniel P . Berrangé, 2019/01/18