Re: Xenvif non-zero byte assertion error during teardown

[Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx>]

On 06/07/2026 11:32, Durrant, Paul wrote:
>>>
>>> What's wrong with zeroing the struct on allocation (which is what is 
>>> supposed to happen)?
>>>
>>
>>
>> Struct padding bytes have unspecified values and compilers are free to
>> emit code that overwrite them even if we don't access them directly. So
>> even if a structure was zeroed on initialization, its padding can't be
>> guaranteed to remain zero on teardown.
> 
> Make the padding explicit then... that should avoid the issue without 
> removing the check (which *has* caught leaks in the past).
> 

Doing so is hard since padding is architecture-dependent, and gets 
complex fast once child structures are involved. Some structures like 
INTERFACE (part of DebugInterface/SuspendInterface/etc) have padding 
that we can't simply eliminate or make explicit.

I've tried to check for padding correctness this way:

     #if DBG
     #define CONCAT2(a, b)   a##b
     #define CONCAT(a, b)    CONCAT2(a, b)

     #define PAD(n)          CHAR    CONCAT(_Pad_, __LINE__)[n]

     #define PAD_CHECK(name, T) \
         struct name T; \
         __pragma(pack(push, 1)) \
         struct _PACKED_##name T \
         __pragma(pack(pop)); \
         _STATIC_ASSERT(sizeof(struct name) == \
             sizeof(struct _PACKED_##name))

     #else
     #define PAD(n)
     #define PAD_CHECK(name, T) \
         struct name T;
     #endif

     PAD_CHECK(_XENVIF_FRONTEND, {
         BOOLEAN                     Online;
         PAD(7);
         KSPIN_LOCK                  Lock;
         // ...
     });

It works for trivial cases, but it breaks as soon as we encounter struct 
INTERFACE.
In any case, the padding content of struct INTERFACE is not guaranteed 
and we may run into the same problem with this struct.


--
Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech