> Am 26.02.2026 um 13:41 schrieb Thomas Huth <[email protected]>:
>
> On 26/02/2026 12.39, Peter Lieven wrote:
>>> Am 26.02.2026 um 12:16 schrieb Daniel P. Berrangé <[email protected]>:
>>>
>>> On Thu, Feb 26, 2026 at 10:44:58AM +0000, Peter Maydell wrote:
>>>> On Tue, 24 Feb 2026 at 18:14, John Snow <[email protected]> wrote:
>>>>>
>>>>> The following changes since commit
>>>>> afe653676dc6dfd49f0390239ff90b2f0052c2b8:
>>>>>
>>>>> Merge tag 'audio-pull-request' of
>>>>> https://gitlab.com/marcandre.lureau/qemu into staging (2026-02-23
>>>>> 14:03:50 +0000)
>>>>>
>>>>> are available in the Git repository at:
>>>>>
>>>>> https://gitlab.com/jsnow/qemu.git tags/python-pull-request
>>>>>
>>>>> for you to fetch changes up to 4e55bb4be53bc7a5e3fe1429af12d2e3090049a5:
>>>>>
>>>>> python: add setuptools and wheel dependencies (2026-02-24 13:11:29 -0500)
>>>>>
>>>>> ----------------------------------------------------------------
>>>>>
>>>>> ----------------------------------------------------------------
>>>>
>>>> Hi -- it looks like this pullreq may have broken the "coverity" job
>>>> that (run on a separate schedule from main CI) does a QEMU build to
>>>> upload to the coverity scan service:
>>>>
>>>> https://gitlab.com/qemu-project/qemu/-/jobs/13264087007
>>>>
>>>> It fails during QEMU configure:
>>>>
>>>> Dependency libnfs found: NO. Found 16.2.0 but need: '<6.0.0' ;
>>>> matched: '>=1.9.3'
>>>> Run-time dependency libnfs found: NO
>>>> ../meson.build:1150:11: ERROR: Dependency lookup for libnfs with
>>>> method 'pkgconfig' failed: Invalid version, need 'libnfs' ['<6.0.0']
>>>> found '16.2.0'.
>>>>
>>>> I'm guessing this is because:
>>>> * the coverity job runs on the amd64-fedora-container
>>>> * we just upgraded our Fedora container to F43
>>>> * coverity configures with --enable-libnfs
>>>
>>> Do we really need to be hardcoding configure options ?
>>>
>>> It is a pretty random subset of options, compared to what gets
>>> enabled in the build.
>>>
>>> Originally we had the hand-built Dockerfile, but now nearly all
>>> our dockerfiles are auto-generated by lcitool, so we get the full
>>> set of QEMU deps on every distro.
>>>
>>> There is a risk that we break a meson/configure chck somewhere,
>>> but IMHO that's not something our coverity needs to be validating
>>> directly. If that happens and we later fix it, coverity would
>>> pick up any flaws that weere introduced in the window it was
>>> broken.
>>>
>>>> * in meson.build we enforce libnfs < 6.0.0
>>>> * F43 ships with a newer libnfs
>>>>
>>>> The "not libnfs v6" restriction was added by thuth in
>>>> commit e2d98f257138 in 2024 because of a big API change in
>>>> libnfs v6. The theory was that this was a temporary hack
>>>> until somebody updated block/nfs.c to handle the new API.
>>>> Over a year later, nobody has touched block/nfs.c...
>>>>
>>>> I guess for the moment we should fix the Coverity build
>>>> by dropping the --enable-libnfs (and accepting that we
>>>> don't scan block/nfs.c any more). For the longer term:
>>>>
>>>> * does anybody want to update block/nfs.c ?
>>>> * or should we mark it as deprecated and plan to eventually
>>>> drop it, given that the set of supported distros you can
>>>> build it on is rapidly shrinking ?
>>>
>>> MAINTAINERS file marks it as "maintained" but given the ongoing
>>> brokeness that feels outdated :-(
>>>
>>> In Fedora we've been carrying a patch to QEMU to enable libnfs
>>> v6.
>>>
>>>
>>> https://src.fedoraproject.org/rpms/qemu/blob/rawhide/f/0002-nfs-Add-support-for-libnfs-v2-api.patch
>>>
>>> https://src.fedoraproject.org/rpms/qemu/blob/rawhide/f/0008-Revert-meson.build-Disallow-libnfs-v6-to-fix-the-bro.patch
>> Sorry, I was not aware of any build problems so far and as I wrote Peter
>> earlier I was some time out of Qemu development, but that changed recently.
>> Is there a reason why Ronnie’s patch never went upstream?
>
> Searching for the subject of that patch in my qemu-devel folder, I don't get
> any results. So I guess that patch has never been posted to the qemu-devel
> mailing list?
That might explain it. I meanwhile had a chance to look into the source of
libnfs v6 it seems that patch is wrong.
It writes bytes number of bytes to the address auf iov->iov[0].iov_base. If
bytes is greater than the iov->iov[0] buffer, it writes beyond the end of the
buffer.
I cannot see at a glance if that’s potentially dangerous, but it might be.
In fact libnfs v6 adds support for supplying a read buffer, but not for
iovectors.
What the patch really should do is to pass iov[0].iov_base if niov == 1 and
create a bounce buffer otherwise.
Peter
