> | for xhci, all of these seem to be the same issue and it
> | appears to be a "high level allocator doesn't know what
> | it is allocating and does not align properly".  the
> | problem is likely:
> | 
> | #define XHCI_TRB_ALIGN 16
> | struct xhci_trb {
> | ...
> | } __packed __aligned(XHCI_TRB_ALIGN);   
> | 
> | which is included in:
> | 
> | struct xhci_softc {
> | ...
> |         struct xhci_trb sc_result_trb;
> | 
> | 
> | ... how do we convey the structure alignment needed for
> | softc, or do we fix it by moving it into its own separate
> | aligned allocation?
> 
> Shouldn't the compiler know how to do this right by padding around the
> structure that needs alignment and assuming the default alignment for
> the enclosing structure?

how can it?  it has to be 16 byte aligned.  the alignment
provided is only 8.  so sometimes the padding will work and
sometimes the padding will fault, depending on what bit 3
is of the returned address.  it may already pad before hand
to get 16 byte alignment from the start of the structure,
as well as force the whole structure alignment to 16, looking
above this member, it's hard to easily tell, it could be
needing 4, 8 or 12 bytes of padding (4/12 only 32 bit only.)

this is why the compiler assumes it must be 16 byte aligned
already -- because that's the only case that is valid.


.mrg.

Reply via email to