This scares me. Seems like you'd be changing the size of the metadata on the disk if you did this.

sizeof(uintptr_t) maybe?

what's wrong with the roundup macro?

This is why I said above in #ifdef guards, and wondering about an appropriate macro to use. Because of this geli does not work today on mips64, so we can either end up with a new on-disk geli format for mips64 or have geli explicitly not supported on mips64.

So md5 requires that we hash into an aligned buffer?

Do we have the same issue with ARM?

Yes md5 requires aligned md_hash. Not sure about ARM

Alternately we could memcpy the md_hash in.

FYI I would expect that alignment of at least 4 is mandated by all of our ABIs.

I'm slightly surprised we'd end up with a misaligned sector[], even if it's not explicitly guaranteed. However, if we do need to explicitly specify alignment there should be no problem (for this stack variable) doing it for all architectures.

We should do it for all architectures. There's no harm, and it may help.

Why not make this an array of uint32_t?

We can do this for all archs. There's no harm.

Ditto.

But honestly, the kernel malloc should returned a properly aligned buffer. Have you verified that it actually doesn't?

Probably something like __aligned(__alignof(struct g_eli_metadata))

__alignof(struct g_eli_metadata) is 1, but we need 4

p is adjusted pointer:

if (bp->bio_cmd == BIO_READ) {
    data = bp->bio_driver2;
    p = auth + sc->sc_alen * nsec;
} else {
    data = malloc(size, M_ELI, M_WAITOK);
    p = data + encr_secsize * nsec;
}
p = (char *)roundup((uintptr_t)p, sizeof(uintptr_t));

Sometimes p comes not aligned after this.