From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
To: herbert@gondor.apana.org.au
Cc: fujita.tomonori@lab.ntt.co.jp, akpm@linux-foundation.org,
linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org,
jens.axboe@oracle.com, tsbogend@alpha.franken.de,
bzolnier@gmail.com, James.Bottomley@HansenPartnership.com,
jeff@garzik.org, davem@davemloft.net, linux-mm@kvack.org
Subject: Re: [PATCH 1/4] block: use ARCH_KMALLOC_MINALIGN as the default dma pad mask
Date: Wed, 21 May 2008 20:01:12 +0900 [thread overview]
Message-ID: <20080521200104C.tomof@acm.org> (raw)
In-Reply-To: <20080521100529.GA19077@gondor.apana.org.au>
On Wed, 21 May 2008 18:05:29 +0800
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, May 21, 2008 at 06:34:45PM +0900, FUJITA Tomonori wrote:
> >
> > Why do crypto need to know exactly the minimum alignment guaranteed by
> > kmalloc? Can you tell me an example how the alignment breaks crypto?
>
> It's used to make the context aligned so that for most algorithms
> we can get to the context without going through ALIGN_PTR. Only
How many bytes does the context need to be aligned?
I'm still not sure what you mean. You referred to aes, so let me use
aes as an example.
I think 'we can get to the context' means that accessing to
crypto_aes_ctx from struct crypto_tfm like this:
struct crypto_aes_ctx *ctx = crypto_tfm_ctx(tfm);
struct crypto_tfm and crypto_tfm_ctx are defined as:
struct crypto_tfm {
u32 crt_flags;
union {
struct ablkcipher_tfm ablkcipher;
struct aead_tfm aead;
struct blkcipher_tfm blkcipher;
struct cipher_tfm cipher;
struct hash_tfm hash;
struct compress_tfm compress;
} crt_u;
struct crypto_alg *__crt_alg;
void *__crt_ctx[] CRYPTO_MINALIGN_ATTR;
};
static inline void *crypto_tfm_ctx(struct crypto_tfm *tfm)
{
return tfm->__crt_ctx;
}
struct crypto_aes_ctx is placed right after struct crypto_tfm.
My question is why __crt_ctx needs ARCH_KMALLOC_MINALIGN alignment,
e.g., could be 128 bytes.
> algorithms requiring alignments bigger than that offered by kmalloc
> would have to use ALIGN_PTR. This is important because the context
> is used on the fast path, i.e., for AES every block has to access
> the context.
Why do algorithms require alignments bigger than ARCH_KMALLOC_MINALIGN?
> If we used an alignment value is bigger than that guaranteed by
> kmalloc then this would break because the context may end up
> unaligned.
>
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
To: herbert@gondor.apana.org.au
Cc: fujita.tomonori@lab.ntt.co.jp, akpm@linux-foundation.org,
linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org,
jens.axboe@oracle.com, tsbogend@alpha.franken.de,
bzolnier@gmail.com, James.Bottomley@HansenPartnership.com,
jeff@garzik.org, davem@davemloft.net, linux-mm@kvack.org
Subject: Re: [PATCH 1/4] block: use ARCH_KMALLOC_MINALIGN as the default dma pad mask
Date: Wed, 21 May 2008 20:01:12 +0900 [thread overview]
Message-ID: <20080521200104C.tomof@acm.org> (raw)
In-Reply-To: <20080521100529.GA19077@gondor.apana.org.au>
On Wed, 21 May 2008 18:05:29 +0800
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, May 21, 2008 at 06:34:45PM +0900, FUJITA Tomonori wrote:
> >
> > Why do crypto need to know exactly the minimum alignment guaranteed by
> > kmalloc? Can you tell me an example how the alignment breaks crypto?
>
> It's used to make the context aligned so that for most algorithms
> we can get to the context without going through ALIGN_PTR. Only
How many bytes does the context need to be aligned?
I'm still not sure what you mean. You referred to aes, so let me use
aes as an example.
I think 'we can get to the context' means that accessing to
crypto_aes_ctx from struct crypto_tfm like this:
struct crypto_aes_ctx *ctx = crypto_tfm_ctx(tfm);
struct crypto_tfm and crypto_tfm_ctx are defined as:
struct crypto_tfm {
u32 crt_flags;
union {
struct ablkcipher_tfm ablkcipher;
struct aead_tfm aead;
struct blkcipher_tfm blkcipher;
struct cipher_tfm cipher;
struct hash_tfm hash;
struct compress_tfm compress;
} crt_u;
struct crypto_alg *__crt_alg;
void *__crt_ctx[] CRYPTO_MINALIGN_ATTR;
};
static inline void *crypto_tfm_ctx(struct crypto_tfm *tfm)
{
return tfm->__crt_ctx;
}
struct crypto_aes_ctx is placed right after struct crypto_tfm.
My question is why __crt_ctx needs ARCH_KMALLOC_MINALIGN alignment,
e.g., could be 128 bytes.
> algorithms requiring alignments bigger than that offered by kmalloc
> would have to use ALIGN_PTR. This is important because the context
> is used on the fast path, i.e., for AES every block has to access
> the context.
Why do algorithms require alignments bigger than ARCH_KMALLOC_MINALIGN?
> If we used an alignment value is bigger than that guaranteed by
> kmalloc then this would break because the context may end up
> unaligned.
>
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-05-21 11:01 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-20 4:58 [PATCH 0/4] revert the commit 22a9189f (cdrom: use kmalloced buffers instead of buffers on stack) FUJITA Tomonori
2008-05-20 4:58 ` [PATCH 1/4] block: use ARCH_KMALLOC_MINALIGN as the default dma pad mask FUJITA Tomonori
2008-05-20 4:58 ` [PATCH 2/4] block: add blk_queue_update_dma_pad FUJITA Tomonori
2008-05-20 4:58 ` [PATCH 3/4] ide: use the dma safe check for REQ_TYPE_ATA_PC FUJITA Tomonori
2008-05-20 4:58 ` [PATCH 4/4] cdrom: revert commit 22a9189 (cdrom: use kmalloced buffers instead of buffers on stack) FUJITA Tomonori
2008-05-20 7:33 ` Elias Oltmanns
2008-05-20 7:42 ` Jim Paris
2008-05-20 8:14 ` Elias Oltmanns
2008-05-28 6:43 ` [PATCH 3/4] ide: use the dma safe check for REQ_TYPE_ATA_PC Borislav Petkov
2008-05-20 9:31 ` [PATCH 1/4] block: use ARCH_KMALLOC_MINALIGN as the default dma pad mask Andrew Morton
2008-05-20 9:31 ` Andrew Morton
2008-05-20 9:38 ` Herbert Xu
2008-05-20 9:38 ` Herbert Xu
2008-05-20 9:52 ` Andrew Morton
2008-05-20 9:52 ` Andrew Morton
2008-05-20 9:58 ` FUJITA Tomonori
2008-05-20 9:58 ` FUJITA Tomonori
2008-05-20 11:32 ` Herbert Xu
2008-05-20 11:32 ` Herbert Xu
2008-05-20 13:25 ` FUJITA Tomonori
2008-05-20 13:25 ` FUJITA Tomonori
2008-05-20 15:34 ` Herbert Xu
2008-05-20 15:34 ` Herbert Xu
2008-05-20 15:53 ` Plans for libsas and SAS-2? Marushak, Nathan
2008-05-20 16:09 ` [PATCH 1/4] block: use ARCH_KMALLOC_MINALIGN as the default dma pad mask FUJITA Tomonori
2008-05-20 16:09 ` FUJITA Tomonori
2008-05-21 1:26 ` Herbert Xu
2008-05-21 1:26 ` Herbert Xu
2008-05-21 1:36 ` FUJITA Tomonori
2008-05-21 1:36 ` FUJITA Tomonori
2008-05-21 3:16 ` Herbert Xu
2008-05-21 3:16 ` Herbert Xu
2008-05-21 6:54 ` FUJITA Tomonori
2008-05-21 6:54 ` FUJITA Tomonori
2008-05-21 8:47 ` Herbert Xu
2008-05-21 8:47 ` Herbert Xu
2008-05-21 9:34 ` FUJITA Tomonori
2008-05-21 9:34 ` FUJITA Tomonori
2008-05-21 10:05 ` Herbert Xu
2008-05-21 10:05 ` Herbert Xu
2008-05-21 11:01 ` FUJITA Tomonori [this message]
2008-05-21 11:01 ` FUJITA Tomonori
2008-05-21 11:25 ` Herbert Xu
2008-05-21 11:25 ` Herbert Xu
2008-05-21 12:09 ` FUJITA Tomonori
2008-05-21 12:09 ` FUJITA Tomonori
2008-05-21 12:22 ` Herbert Xu
2008-05-21 12:22 ` Herbert Xu
2008-05-21 12:46 ` FUJITA Tomonori
2008-05-21 12:46 ` FUJITA Tomonori
2008-05-21 12:55 ` FUJITA Tomonori
2008-05-21 12:55 ` FUJITA Tomonori
2008-05-21 13:19 ` Herbert Xu
2008-05-21 13:19 ` Herbert Xu
2008-05-21 13:18 ` Herbert Xu
2008-05-21 13:18 ` Herbert Xu
2008-05-22 1:14 ` FUJITA Tomonori
2008-05-22 1:14 ` FUJITA Tomonori
2008-05-22 1:19 ` David Miller
2008-05-22 1:19 ` David Miller, FUJITA Tomonori
2008-05-22 1:21 ` Herbert Xu
2008-05-22 1:21 ` Herbert Xu
2008-05-22 1:32 ` FUJITA Tomonori
2008-05-22 1:32 ` FUJITA Tomonori
2008-05-22 1:56 ` Herbert Xu
2008-05-22 1:56 ` Herbert Xu
2008-05-20 9:55 ` Paul Mundt
2008-05-20 9:55 ` Paul Mundt
2008-05-21 22:11 ` [PATCH 0/4] revert the commit 22a9189f (cdrom: use kmalloced buffers instead of buffers on stack) Thomas Bogendoerfer
2008-05-22 1:13 ` FUJITA Tomonori
2008-05-22 1:18 ` David Miller
2008-05-22 8:43 ` James Bottomley
2008-05-26 9:17 ` FUJITA Tomonori
2008-05-27 18:58 ` Bartlomiej Zolnierkiewicz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080521200104C.tomof@acm.org \
--to=fujita.tomonori@lab.ntt.co.jp \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=bzolnier@gmail.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=jeff@garzik.org \
--cc=jens.axboe@oracle.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-scsi@vger.kernel.org \
--cc=tsbogend@alpha.franken.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.