On 02/13/2015 08:49 AM, Markus Stockhausen wrote:
> thanks for the tip. I will at least move the data definitions to the
> beginning of
> my structure.
>
> But while it sounds logical for data types that are directly created from
> that
> structure I'm unsure about a context. If I understand it correctly a context
> is
> dynamically allocated. Could it be possible that the start address is then
> only
> 4 bytes aligned?
>
> So I tried to dive into the magic of alignmask and contexts. This even
> confuses
> me a little bit more. Nearly all implementations in the crypto tree make use
> of
> alignmasks >= 3. I guess to be at least 4 bytes aligned. But when accessing
> the
> context they "only" use crypto_blkcipher_ctx(). This will just return the
> context
> address while crypto_blkcipher_ctx_aligned() seems to be the right place to
> return a pointer that is aligned according to the predefined mask.
>
> Would you recommend to
>
> a) ignore alignmask and use only __aligned(8) for the structure
>
> b) to assume ctx will be automatically 8 bytes aligned regardless of
> __aligned(8)
> flag or cra_alignmask. So nothing to take care about.
>
> b) or to define structure without __aligned(8) but work with cra_alignmask=7.
> I fear that this might impose alignment of input/output data to 8 too and
> lead
> to unneccessary memcpy() operations.
>
> Sorry for driving myself nuts but I want to understand if before I send
> patches.
In this case I think the best way is to define your algorithm with
.cra_ctxsize = sizeof(struct ppc_aes_ctx) + 8,
and then in enc/dec/setkey do
struct ppc_aes_ctx *ctx = PTR_ALIGN(crypto_tfm_ctx(tfm), 8);
and you don't need the __aligned(8) in the struct definition.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
