On Wed, Jun 08, 2016 at 09:16:52AM +0100, Giovanni Cabiddu wrote:
>
> +static void *scomp_map(struct scatterlist *sg, unsigned int len,
> + gfp_t gfp_flags)
> +{
> + void *buf;
> +
> + if (sg_is_last(sg))
> + return kmap_atomic(sg_page(sg)) + sg->offset;
This doesn't work, because kmap_atomic maps a single page only
bug an SG entry can be a super-page, e.g., a set of contiguous
pages.
> + buf = kmalloc(len, gfp_flags);
The backup path is also very unlikely to work because we'll be
hitting this with 64K sizes and this just won't work with a 4K
page size.
So up until now we've getting around this 64K issue with vmalloc,
and then we try to conserve the precious vmalloc resource by using
per-cpu allocation.
This totally breaks down once you go to DMA, where an SG list is
required. Unfortunately, this means that there is no easy way
to linearise the data for our software implementations.
There is no easy way out I'm afraid. I think we'll have to bite
the bullet and refit our software algos so that they handle SG
lists.
Not only will this solve the problem at hand, it'll also mean that
acomp users will never have to do vmalloc so it's a win-win. It
also means that we won't need the scomp interface at all.
This does bring up another question of who should be allocating the
output memory. Up until now it has been up to the user to do so.
However, if our algos can actually handle SG lists then I think it
should be fairly easy to make them do the allocation instead. What
do you think?
Thanks,
--
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
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-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
