> From: Burakov, Anatoly [mailto:[email protected]] > Sent: Friday, 22 May 2026 11.46 > > On 5/8/2026 11:16 AM, Morten Brørup wrote: > >> From: Burakov, Anatoly [mailto:[email protected]] > >> Sent: Thursday, 7 May 2026 10.09 > >> > >> On 5/6/2026 5:58 PM, David Marchand wrote: > >>> On Wed, 6 May 2026 at 16:07, Anatoly Burakov > >> <[email protected]> wrote: > >>>> > >>>> The PF will check buffer size for being too big, and the chunk > >> sizing code > >>>> correctly calls that out. However, the size was actually still too > >> big > >>>> because `struct virtchnl_queue_vector_maps` already had one queue > >> vector > >>>> as part of its definition, so `chunk_sz` was too big by 1. > >>>> > >>>> Fixes: 292d3b781ac4 ("net/iavf: replace unnecessary hugepage > memory > >> allocations") > >>>> > >>>> Signed-off-by: Anatoly Burakov <[email protected]> > >>>> --- > >>>> drivers/net/intel/iavf/iavf_vchnl.c | 2 +- > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>> > >>>> diff --git a/drivers/net/intel/iavf/iavf_vchnl.c > >> b/drivers/net/intel/iavf/iavf_vchnl.c > >>>> index c2f340db81..dd09b0fa61 100644 > >>>> --- a/drivers/net/intel/iavf/iavf_vchnl.c > >>>> +++ b/drivers/net/intel/iavf/iavf_vchnl.c > >>>> @@ -1528,7 +1528,7 @@ iavf_config_irq_map_lv_chunk(struct > >> iavf_adapter *adapter, > >>>> > >>>> /* for some reason PF side checks for buffer being too > big, > >> so adjust it down */ > >>> > >>> The comment above can be removed? > >> > >> No, it's still relevant, because it refers to the fact that we're > >> adjusting the total length downwards as opposed to leaving it at max > >> size. > >> > >>> > >>>> buf_len = sizeof(struct virtchnl_queue_vector_maps) + > >>>> - sizeof(struct virtchnl_queue_vector) * chunk_sz; > >>>> + sizeof(struct virtchnl_queue_vector) * (chunk_sz > - > >> 1); > >>> > >>> - did you make sure you did not break compat with previous version > of > >>> Intel out of tree PF driver (since this concerns configuring "Large > >>> VF")? > >> > >> The commit in question *did* break things with previous out of tree > PF > >> driver. This commit fixes the breakage introduced in that commit. > The > >> commit being fixed was a refactor, which specified size as N-1. > >> > >>> > >>> - all those virtchnl list struct have the same elems[1] issue. > >>> Kernel side did some cleanups some time ago, maybe time for DPDK to > >> do > >>> the same...? > >>> > >> > >> Yes, it is indeed time to do the same, but not as part of this > >> patchset, > >> and not before the base driver code is updated to do the same. There > is > >> some background work happening on that front already, but there are > a > >> lot of dependencies and moving parts, so we can't just change this > >> willy > >> nilly. > > > > Is there a timeline for this fix? > > > > No specific timeline, unfortunately.
The drivers were very recently updated to use memcpy() instead of rte_memcpy(), so now we can enable stringop-overflow warnings in rte_memcpy(). What really annoyed me was the need to disable these warnings in a general library function due to some drivers. Since this problem has now been resolved, and the scope of the elems[1] problem has shrunk from system-wide to Intel drivers only, I'm not that concerned about timeline anymore. ;-) -Morten
