diff mbox

[v2,04/10] crypto/compress: add asynchronous compression support

Message ID 1453796112-14273-5-git-send-email-iamjoonsoo.kim@lge.com (mailing list archive)
State Changes Requested
Delegated to: Herbert Xu
Headers show

Commit Message

Joonsoo Kim Jan. 26, 2016, 8:15 a.m. UTC
From: Weigang Li <weigang.li@intel.com>

Now, asynchronous compression APIs are supported. There is no asynchronous
compression driver now but this APIs can be used as front-end to
synchronous compression algorithm. In this case, scatterlist would be
linearlized when needed so it would cause some overhead.

Signed-off-by: Weigang Li <weigang.li@intel.com>
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
---
 crypto/Kconfig                     |   3 +-
 crypto/Makefile                    |   3 +-
 crypto/acompress.c                 | 164 ++++++++++++++++++++++++
 crypto/scompress.c                 | 170 +++++++++++++++++++++++++
 include/crypto/compress.h          | 253 +++++++++++++++++++++++++++++++++++++
 include/crypto/internal/compress.h |   4 +
 include/linux/crypto.h             |   2 +
 7 files changed, 596 insertions(+), 3 deletions(-)
 create mode 100644 crypto/acompress.c
 create mode 100644 include/crypto/internal/compress.h

Comments

Herbert Xu Jan. 27, 2016, 7:41 a.m. UTC | #1
On Tue, Jan 26, 2016 at 05:15:06PM +0900, Joonsoo Kim wrote:
> From: Weigang Li <weigang.li@intel.com>
> 
> Now, asynchronous compression APIs are supported. There is no asynchronous
> compression driver now but this APIs can be used as front-end to
> synchronous compression algorithm. In this case, scatterlist would be
> linearlized when needed so it would cause some overhead.
> 
> Signed-off-by: Weigang Li <weigang.li@intel.com>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>

I think we should be able to use this for the synchronous case
too, like we do with skcipher and ahash.

The main difference that I can see right now is that acomp always
allocates a context through the request object while scomp does not.

This difference is entirely artificial as we could also make the
context conditional for acomp.

The reason we had the shash/ahash division is because the shash
interface offers a direct pointer interface while ahash is SG-based.
Otherwise ahash is just as able as shash to handle synchronous
requests.

At this point in time I don't see such a fundamental distinction
between acomp and scomp.

Cheers,
Weigang Li Jan. 27, 2016, 7:59 a.m. UTC | #2
On 1/27/2016 3:41 PM, Herbert Xu wrote:
> On Tue, Jan 26, 2016 at 05:15:06PM +0900, Joonsoo Kim wrote:
>> From: Weigang Li <weigang.li@intel.com>
>>
>> Now, asynchronous compression APIs are supported. There is no asynchronous
>> compression driver now but this APIs can be used as front-end to
>> synchronous compression algorithm. In this case, scatterlist would be
>> linearlized when needed so it would cause some overhead.
>>
>> Signed-off-by: Weigang Li <weigang.li@intel.com>
>> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>
> I think we should be able to use this for the synchronous case
> too, like we do with skcipher and ahash.
>
> The main difference that I can see right now is that acomp always
> allocates a context through the request object while scomp does not.
>
> This difference is entirely artificial as we could also make the
> context conditional for acomp.
>
> The reason we had the shash/ahash division is because the shash
> interface offers a direct pointer interface while ahash is SG-based.
> Otherwise ahash is just as able as shash to handle synchronous
> requests.
>
> At this point in time I don't see such a fundamental distinction
> between acomp and scomp.
>
> Cheers,
>
The acomp is also SG-based, while scomp only accepts flat buffer.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Herbert Xu Jan. 27, 2016, 8:03 a.m. UTC | #3
On Wed, Jan 27, 2016 at 03:59:05PM +0800, Li, Weigang wrote:
>
> The acomp is also SG-based, while scomp only accepts flat buffer.

Right, but do we need a pointer-based scomp at all? IPComp would
certainly be better off with an SG-based interface.  Any other
users of compression are presumably dealing with large amounts
of data where an SG interface would make more sense.

A pointer interface makes sense for shash because you may be hashing
16 bytes at a time.  Nobody sane is going to be compressing 16 bytes,
or are they?

Cheers,
Herbert Xu Jan. 27, 2016, 8:09 a.m. UTC | #4
On Wed, Jan 27, 2016 at 04:03:55PM +0800, Herbert Xu wrote:
> On Wed, Jan 27, 2016 at 03:59:05PM +0800, Li, Weigang wrote:
> >
> > The acomp is also SG-based, while scomp only accepts flat buffer.
> 
> Right, but do we need a pointer-based scomp at all? IPComp would
> certainly be better off with an SG-based interface.  Any other
> users of compression are presumably dealing with large amounts
> of data where an SG interface would make more sense.
> 
> A pointer interface makes sense for shash because you may be hashing
> 16 bytes at a time.  Nobody sane is going to be compressing 16 bytes,
> or are they?

Note that I'm fine with keeping an scomp interface underneath
for those algorithms where the best way to handle SG input is
to linearise things.  But I would prefer that this interface is
not exposed to kernel users unless it is absolutely required.

Cheers,
Weigang Li Jan. 27, 2016, 8:26 a.m. UTC | #5
On 1/27/2016 4:09 PM, Herbert Xu wrote:
> On Wed, Jan 27, 2016 at 04:03:55PM +0800, Herbert Xu wrote:
>> On Wed, Jan 27, 2016 at 03:59:05PM +0800, Li, Weigang wrote:
>>>
>>> The acomp is also SG-based, while scomp only accepts flat buffer.
>>
>> Right, but do we need a pointer-based scomp at all? IPComp would
>> certainly be better off with an SG-based interface.  Any other
>> users of compression are presumably dealing with large amounts
>> of data where an SG interface would make more sense.
>>
>> A pointer interface makes sense for shash because you may be hashing
>> 16 bytes at a time.  Nobody sane is going to be compressing 16 bytes,
>> or are they?
>
> Note that I'm fine with keeping an scomp interface underneath
> for those algorithms where the best way to handle SG input is
> to linearise things.  But I would prefer that this interface is
> not exposed to kernel users unless it is absolutely required.
>
> Cheers,
>
Thanks for your comments, Herbert. I Agree, SG-list based compression 
API makes more sense. Maybe Joonsoo can comment on this.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Joonsoo Kim Jan. 28, 2016, 3:19 a.m. UTC | #6
Hello, Herbert.

On Wed, Jan 27, 2016 at 04:09:26PM +0800, Herbert Xu wrote:
> On Wed, Jan 27, 2016 at 04:03:55PM +0800, Herbert Xu wrote:
> > On Wed, Jan 27, 2016 at 03:59:05PM +0800, Li, Weigang wrote:
> > >
> > > The acomp is also SG-based, while scomp only accepts flat buffer.
> > 
> > Right, but do we need a pointer-based scomp at all? IPComp would
> > certainly be better off with an SG-based interface.  Any other
> > users of compression are presumably dealing with large amounts
> > of data where an SG interface would make more sense.
> > 
> > A pointer interface makes sense for shash because you may be hashing
> > 16 bytes at a time.  Nobody sane is going to be compressing 16 bytes,
> > or are they?

Hmm... I'm not an expert on this area so below of my analysis would be
wrong.

Some of compression example in kernel do compression with PAGE_SIZE and
compressed size is naturally less than PAGE_SIZE. There are many cases
that compressed size is below than 100 bytes. To keep and handle data,
they somtimes use kmalloced buffer and I guess it isn't suitable for
SG-based interface. Is it okay to use SG-based interface
if kmalloced object covers two pages?

And, even, someone uses vmalloced buffer that's also not suitable for
SG-based interface. For large amount data case, vmalloced buffer is
more suitable and it needs pointer interface.

> Note that I'm fine with keeping an scomp interface underneath
> for those algorithms where the best way to handle SG input is
> to linearise things.  But I would prefer that this interface is
> not exposed to kernel users unless it is absolutely required.

I have tested asynchronous compression APIs in zram and I saw
regression. Atomic allocation and setting up SG lists are culprit
for this regression. Moreover, zram optimizes linearisation
to get the best performance so it has two Kconfig options. One of
them cannot be support in the general layer. Not supporting pointer
based APIs unavoidably causes regression to zram in this case.

And, S/W compression algorithms that exists in kernel
are pointer based so it's natural to support it first
in crypto compression. That will help existing users to change
their direct library call to crypto compression without any regression.
They may be happy to change it because they just could get more
algorithm support without any loss.

I think that supporting pointer-based interface has some merits
mentioned above. However, I'm not sure what's the benefit if we only
support SG-based interface and it's bigger than above.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Herbert Xu Jan. 29, 2016, 10:09 a.m. UTC | #7
On Thu, Jan 28, 2016 at 12:19:42PM +0900, Joonsoo Kim wrote:
>
> I have tested asynchronous compression APIs in zram and I saw
> regression. Atomic allocation and setting up SG lists are culprit
> for this regression. Moreover, zram optimizes linearisation

So which is it, atomic allocations or setting up SG lists? There
is nothing in acomp that requires you to do an atomic allocation.

Cheers,
Joonsoo Kim Feb. 1, 2016, 2:11 a.m. UTC | #8
On Fri, Jan 29, 2016 at 06:09:01PM +0800, Herbert Xu wrote:
> On Thu, Jan 28, 2016 at 12:19:42PM +0900, Joonsoo Kim wrote:
> >
> > I have tested asynchronous compression APIs in zram and I saw
> > regression. Atomic allocation and setting up SG lists are culprit
> > for this regression. Moreover, zram optimizes linearisation
> 
> So which is it, atomic allocations or setting up SG lists? There
> is nothing in acomp that requires you to do an atomic allocation.

Atomic allocation are called for linearisation when needed. Zram's
compressed content is usually stored in two physically separate pages
so linearisation is needed. See scomp_map().

Setting up SG lists means that to use acomp, sg_init_table(),
sg_set_page() are need to be called by zram unlike the case just
passing the pointer based buffer.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Weigang Li Feb. 4, 2016, 3:25 a.m. UTC | #9
On 2/1/2016 10:11 AM, Joonsoo Kim wrote:
> On Fri, Jan 29, 2016 at 06:09:01PM +0800, Herbert Xu wrote:
>> On Thu, Jan 28, 2016 at 12:19:42PM +0900, Joonsoo Kim wrote:
>>>
>>> I have tested asynchronous compression APIs in zram and I saw
>>> regression. Atomic allocation and setting up SG lists are culprit
>>> for this regression. Moreover, zram optimizes linearisation
>>
>> So which is it, atomic allocations or setting up SG lists? There
>> is nothing in acomp that requires you to do an atomic allocation.
>
> Atomic allocation are called for linearisation when needed. Zram's
> compressed content is usually stored in two physically separate pages
> so linearisation is needed. See scomp_map().
>
> Setting up SG lists means that to use acomp, sg_init_table(),
> sg_set_page() are need to be called by zram unlike the case just
> passing the pointer based buffer.
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Hello Herbert & Joonsoo,
Please can you advise how to get the acomp patch accepted?
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Herbert Xu Feb. 4, 2016, 3:28 a.m. UTC | #10
On Thu, Feb 04, 2016 at 11:25:27AM +0800, Li, Weigang wrote:
>
> Please can you advise how to get the acomp patch accepted?

Can you do a posting of these patches without scomp so we can
evaluate the effects?

Thanks!
Herbert Xu Feb. 4, 2016, 3:29 a.m. UTC | #11
On Thu, Feb 04, 2016 at 11:28:50AM +0800, Herbert Xu wrote:
> On Thu, Feb 04, 2016 at 11:25:27AM +0800, Li, Weigang wrote:
> >
> > Please can you advise how to get the acomp patch accepted?
> 
> Can you do a posting of these patches without scomp so we can
> evaluate the effects?

Of course you can keep the driver-side scomp interface as otherwise
the implementation would be unnecessarily complicated.

Cheers,
Weigang Li Feb. 4, 2016, 3:50 a.m. UTC | #12
On 2/4/2016 11:29 AM, Herbert Xu wrote:
> On Thu, Feb 04, 2016 at 11:28:50AM +0800, Herbert Xu wrote:
>> On Thu, Feb 04, 2016 at 11:25:27AM +0800, Li, Weigang wrote:
>>>
>>> Please can you advise how to get the acomp patch accepted?
>>
>> Can you do a posting of these patches without scomp so we can
>> evaluate the effects?
>
> Of course you can keep the driver-side scomp interface as otherwise
> the implementation would be unnecessarily complicated.
>
> Cheers,
>
Seems I need go back to my first acomp patch.. Assuming we shall still 
keep the comp i/f, and the linearisation of sg-list in acomp to fit the 
"comp" API? What do you mean by the driver-side scomp? Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Joonsoo Kim Feb. 4, 2016, 7:17 a.m. UTC | #13
2016-02-04 12:28 GMT+09:00 Herbert Xu <herbert@gondor.apana.org.au>:
> On Thu, Feb 04, 2016 at 11:25:27AM +0800, Li, Weigang wrote:
>>
>> Please can you advise how to get the acomp patch accepted?
>
> Can you do a posting of these patches without scomp so we can
> evaluate the effects?
>

Do you think not to merge scomp? Please let me know your overall
plan about this.?

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Herbert Xu Feb. 4, 2016, 2:53 p.m. UTC | #14
On Thu, Feb 04, 2016 at 04:17:41PM +0900, Joonsoo Kim wrote:
>
> Do you think not to merge scomp? Please let me know your overall
> plan about this.?

I'm fine with a driver-side scomp interface.  But I'd rather
avoid having yet another user-side compression interface in the
form of scomp if we can avoid it.

Cheers,
Herbert Xu Feb. 4, 2016, 2:56 p.m. UTC | #15
On Thu, Feb 04, 2016 at 11:50:46AM +0800, Li, Weigang wrote:
>
> Seems I need go back to my first acomp patch.. Assuming we shall
> still keep the comp i/f, and the linearisation of sg-list in acomp
> to fit the "comp" API? What do you mean by the driver-side scomp?

What I mean is that the bottom half of the scomp patches can still
be used.  We just want to hide it away from the users so won't
provide the direct entry points such as crypto_alloc_scomp, etc..

Cheers,
Joonsoo Kim Feb. 4, 2016, 4:19 p.m. UTC | #16
2016-02-04 23:53 GMT+09:00 Herbert Xu <herbert@gondor.apana.org.au>:
> On Thu, Feb 04, 2016 at 04:17:41PM +0900, Joonsoo Kim wrote:
>>
>> Do you think not to merge scomp? Please let me know your overall
>> plan about this.?
>
> I'm fine with a driver-side scomp interface.  But I'd rather
> avoid having yet another user-side compression interface in the
> form of scomp if we can avoid it.

I mentioned that there are usecases that scomp is needed for performance,
it means that we can't avoid it. Or do you think this usecase differently?
I understand it's rather pain that we have two interfaces but scomp interface
is just wrapping layer to handle various S/W compression algorithms and
implementation is not that complex. I guess it doesn't cause much
maintenance cost.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 7159520..f22f4e9 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -84,7 +84,7 @@  config CRYPTO_RNG_DEFAULT
 	tristate
 	select CRYPTO_DRBG_MENU
 
-config CRYPTO_SCOMPRESS
+config CRYPTO_COMPRESS2
 	tristate
 	select CRYPTO_ALGAPI2
 
@@ -1503,7 +1503,6 @@  config CRYPTO_LZO
 	select CRYPTO_ALGAPI
 	select LZO_COMPRESS
 	select LZO_DECOMPRESS
-	select SCOMPRESS
 	help
 	  This is the LZO algorithm.
 
diff --git a/crypto/Makefile b/crypto/Makefile
index 16ef796..9157d69 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -28,7 +28,8 @@  crypto_hash-y += ahash.o
 crypto_hash-y += shash.o
 obj-$(CONFIG_CRYPTO_HASH2) += crypto_hash.o
 
-obj-$(CONFIG_CRYPTO_SCOMPRESS) += scompress.o
+crypto_compress-y += scompress.o acompress.o
+obj-$(CONFIG_CRYPTO_COMPRESS2) += crypto_compress.o
 obj-$(CONFIG_CRYPTO_AKCIPHER2) += akcipher.o
 
 $(obj)/rsapubkey-asn1.o: $(obj)/rsapubkey-asn1.c $(obj)/rsapubkey-asn1.h
diff --git a/crypto/acompress.c b/crypto/acompress.c
new file mode 100644
index 0000000..ddaa5a0
--- /dev/null
+++ b/crypto/acompress.c
@@ -0,0 +1,164 @@ 
+/*
+ * Asynchronous compression operations
+ *
+ * Copyright (c) 2015, Intel Corporation
+ * Authors: Weigang Li <weigang.li@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ */
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/seq_file.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/crypto.h>
+
+#include <crypto/algapi.h>
+#include <linux/cryptouser.h>
+#include <net/netlink.h>
+#include <crypto/compress.h>
+#include <crypto/internal/compress.h>
+#include "internal.h"
+
+const struct crypto_type crypto_acomp_type;
+
+#ifdef CONFIG_NET
+static int crypto_acomp_report(struct sk_buff *skb, struct crypto_alg *alg)
+{
+	struct crypto_report_comp racomp;
+
+	strncpy(racomp.type, "acomp", sizeof(racomp.type));
+
+	if (nla_put(skb, CRYPTOCFGA_REPORT_COMPRESS,
+		    sizeof(struct crypto_report_comp), &racomp))
+		goto nla_put_failure;
+	return 0;
+
+nla_put_failure:
+	return -EMSGSIZE;
+}
+#else
+static int crypto_acomp_report(struct sk_buff *skb, struct crypto_alg *alg)
+{
+	return -ENOSYS;
+}
+#endif
+
+static void crypto_acomp_show(struct seq_file *m, struct crypto_alg *alg)
+	__attribute__ ((unused));
+
+static void crypto_acomp_show(struct seq_file *m, struct crypto_alg *alg)
+{
+	seq_puts(m, "type         : acomp\n");
+}
+
+static void crypto_acomp_exit_tfm(struct crypto_tfm *tfm)
+{
+	struct crypto_acomp *acomp = __crypto_acomp_tfm(tfm);
+	struct acomp_alg *alg = crypto_acomp_alg(acomp);
+
+	alg->exit(acomp);
+}
+
+static int crypto_acomp_init_tfm(struct crypto_tfm *tfm)
+{
+	struct crypto_acomp *acomp = __crypto_acomp_tfm(tfm);
+	struct acomp_alg *alg = crypto_acomp_alg(acomp);
+
+	if (tfm->__crt_alg->cra_type != &crypto_acomp_type)
+		return crypto_init_scomp_ops_async(tfm);
+
+	acomp->compress = alg->compress;
+	acomp->decompress = alg->decompress;
+
+	if (alg->exit)
+		acomp->base.exit = crypto_acomp_exit_tfm;
+
+	if (alg->init)
+		return alg->init(acomp);
+
+	return 0;
+}
+
+static unsigned int crypto_acomp_extsize(struct crypto_alg *alg)
+{
+	if (alg->cra_type == &crypto_acomp_type)
+		return alg->cra_ctxsize;
+
+	return sizeof(void *);
+}
+
+const struct crypto_type crypto_acomp_type = {
+	.extsize = crypto_acomp_extsize,
+	.init_tfm = crypto_acomp_init_tfm,
+#ifdef CONFIG_PROC_FS
+	.show = crypto_acomp_show,
+#endif
+	.report = crypto_acomp_report,
+	.maskclear = ~CRYPTO_ALG_TYPE_MASK,
+	.maskset = CRYPTO_ALG_TYPE_ACOMPRESS_MASK,
+	.type = CRYPTO_ALG_TYPE_ACOMPRESS,
+	.tfmsize = offsetof(struct crypto_acomp, base),
+};
+EXPORT_SYMBOL_GPL(crypto_acomp_type);
+
+struct crypto_acomp *crypto_alloc_acomp(const char *alg_name, u32 type,
+					u32 mask)
+{
+	return crypto_alloc_tfm(alg_name, &crypto_acomp_type, type, mask);
+}
+EXPORT_SYMBOL_GPL(crypto_alloc_acomp);
+
+struct acomp_req *acomp_request_alloc(struct crypto_acomp *acomp,
+						gfp_t gfp)
+{
+	struct crypto_tfm *tfm = crypto_acomp_tfm(acomp);
+	struct acomp_req *req;
+
+	if (tfm->__crt_alg->cra_type != &crypto_acomp_type)
+		return crypto_scomp_acomp_request_alloc(acomp, gfp);
+
+	req = kzalloc(sizeof(*req) + crypto_acomp_reqsize(acomp), gfp);
+	if (likely(req))
+		acomp_request_set_tfm(req, acomp);
+
+	return req;
+}
+EXPORT_SYMBOL_GPL(acomp_request_alloc);
+
+void acomp_request_free(struct acomp_req *req)
+{
+	struct crypto_acomp *acomp = crypto_acomp_reqtfm(req);
+	struct crypto_tfm *tfm = crypto_acomp_tfm(acomp);
+
+	if (tfm->__crt_alg->cra_type != &crypto_acomp_type)
+		return crypto_scomp_acomp_request_free(req);
+
+	kfree(req);
+}
+EXPORT_SYMBOL_GPL(acomp_request_free);
+
+int crypto_register_acomp(struct acomp_alg *alg)
+{
+	struct crypto_alg *base = &alg->base;
+
+	base->cra_type = &crypto_acomp_type;
+	base->cra_flags &= ~CRYPTO_ALG_TYPE_MASK;
+	base->cra_flags |= CRYPTO_ALG_TYPE_ACOMPRESS;
+	return crypto_register_alg(base);
+}
+EXPORT_SYMBOL_GPL(crypto_register_acomp);
+
+int crypto_unregister_acomp(struct acomp_alg *alg)
+{
+	return crypto_unregister_alg(&alg->base);
+}
+EXPORT_SYMBOL_GPL(crypto_unregister_acomp);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Asynchronous compression type");
diff --git a/crypto/scompress.c b/crypto/scompress.c
index 7c9955b..e5ebf24 100644
--- a/crypto/scompress.c
+++ b/crypto/scompress.c
@@ -24,8 +24,12 @@ 
 #include <linux/module.h>
 #include <linux/seq_file.h>
 #include <linux/cryptouser.h>
+#include <linux/vmalloc.h>
+#include <linux/highmem.h>
+#include <linux/gfp.h>
 
 #include <crypto/compress.h>
+#include <crypto/scatterwalk.h>
 #include <net/netlink.h>
 
 #include "internal.h"
@@ -90,6 +94,172 @@  struct crypto_scomp *crypto_alloc_scomp(const char *alg_name, u32 type,
 }
 EXPORT_SYMBOL_GPL(crypto_alloc_scomp);
 
+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;
+
+	if (in_atomic() || irqs_disabled())
+		gfp_flags = GFP_ATOMIC;
+	else
+		gfp_flags = GFP_KERNEL;
+
+	buf = kmalloc(len, gfp_flags);
+	if (!buf)
+		return NULL;
+
+	scatterwalk_map_and_copy(buf, sg, 0, len, 0);
+
+	return buf;
+}
+
+static void scomp_unmap(struct scatterlist *sg, void *buf, unsigned int len)
+{
+	if (!buf)
+		return;
+
+	if (sg_is_last(sg)) {
+		kunmap_atomic(buf);
+		return;
+	}
+
+	scatterwalk_map_and_copy(buf, sg, 0, len, 1);
+	kfree(buf);
+}
+
+static int scomp_acomp_compress(struct acomp_req *req,
+			 struct crypto_acomp *tfm)
+{
+	int ret;
+	void **tfm_ctx = crypto_acomp_ctx(tfm);
+	struct crypto_scomp *scomp = (struct crypto_scomp *)*tfm_ctx;
+	void *ctx = *(req->__ctx);
+	char *src = scomp_map(req->src, req->src_len);
+	char *dst = scomp_map(req->dst, req->dst_len);
+
+	if (!src || !dst) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	req->out_len = req->dst_len;
+	ret = crypto_scomp_compress(scomp, src, req->src_len,
+				dst, &req->out_len, ctx);
+
+out:
+	scomp_unmap(req->src, src, 0);
+	scomp_unmap(req->dst, dst, ret ? 0 : req->out_len);
+
+	return ret;
+}
+
+static int scomp_async_compress(struct acomp_req *req)
+{
+	return scomp_acomp_compress(req, crypto_acomp_reqtfm(req));
+}
+
+static int scomp_acomp_decompress(struct acomp_req *req,
+			   struct crypto_acomp *tfm)
+{
+	int ret;
+	void **tfm_ctx = crypto_acomp_ctx(tfm);
+	struct crypto_scomp *scomp = (struct crypto_scomp *)*tfm_ctx;
+	void *ctx = *(req->__ctx);
+	char *src = scomp_map(req->src, req->src_len);
+	char *dst = scomp_map(req->dst, req->dst_len);
+
+	if (!src || !dst) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	req->out_len = req->dst_len;
+	ret = crypto_scomp_decompress(scomp, src, req->src_len,
+				dst, &req->out_len, ctx);
+
+out:
+	scomp_unmap(req->src, src, 0);
+	scomp_unmap(req->dst, dst, ret ? 0 : req->out_len);
+
+	return ret;
+}
+
+static int scomp_async_decompress(struct acomp_req *req)
+{
+	return scomp_acomp_decompress(req, crypto_acomp_reqtfm(req));
+}
+
+static void crypto_exit_scomp_ops_async(struct crypto_tfm *tfm)
+{
+	struct crypto_scomp **ctx = crypto_tfm_ctx(tfm);
+
+	crypto_free_scomp(*ctx);
+}
+
+int crypto_init_scomp_ops_async(struct crypto_tfm *tfm)
+{
+	struct crypto_alg *calg = tfm->__crt_alg;
+	struct crypto_acomp *acomp = __crypto_acomp_tfm(tfm);
+	struct crypto_scomp *scomp;
+	void **ctx = crypto_tfm_ctx(tfm);
+
+	if (!crypto_mod_get(calg))
+		return -EAGAIN;
+
+	scomp = crypto_create_tfm(calg, &crypto_scomp_type);
+	if (IS_ERR(scomp)) {
+		crypto_mod_put(calg);
+		return PTR_ERR(scomp);
+	}
+
+	*ctx = scomp;
+	tfm->exit = crypto_exit_scomp_ops_async;
+
+	acomp->compress = scomp_async_compress;
+	acomp->decompress = scomp_async_decompress;
+	acomp->reqsize = sizeof(void *);
+
+	return 0;
+}
+
+struct acomp_req *crypto_scomp_acomp_request_alloc(struct crypto_acomp *tfm,
+							gfp_t gfp)
+{
+	void **tfm_ctx = crypto_acomp_ctx(tfm);
+	struct crypto_scomp *scomp = (struct crypto_scomp *)*tfm_ctx;
+	struct acomp_req *req;
+	void *ctx;
+
+	req = kzalloc(sizeof(*req) + crypto_acomp_reqsize(tfm), gfp);
+	if (!req)
+		return NULL;
+
+	ctx = crypto_scomp_alloc_ctx(scomp);
+	if (IS_ERR(ctx)) {
+		kfree(req);
+		return NULL;
+	}
+
+	*(req->__ctx) = ctx;
+	acomp_request_set_tfm(req, tfm);
+
+	return req;
+}
+
+void crypto_scomp_acomp_request_free(struct acomp_req *req)
+{
+	struct crypto_acomp *tfm = crypto_acomp_reqtfm(req);
+	void **tfm_ctx = crypto_acomp_ctx(tfm);
+	struct crypto_scomp *scomp = (struct crypto_scomp *)*tfm_ctx;
+	void *ctx = *(req->__ctx);
+
+	crypto_scomp_free_ctx(scomp, ctx);
+	kfree(req);
+}
+
 int crypto_register_scomp(struct scomp_alg *alg)
 {
 	struct crypto_alg *base = &alg->base;
diff --git a/include/crypto/compress.h b/include/crypto/compress.h
index e4053fc..5b6332d 100644
--- a/include/crypto/compress.h
+++ b/include/crypto/compress.h
@@ -90,4 +90,257 @@  static inline bool crypto_scomp_decomp_noctx(struct crypto_scomp *tfm)
 
 extern int crypto_register_scomp(struct scomp_alg *alg);
 extern int crypto_unregister_scomp(struct scomp_alg *alg);
+
+/**
+ * struct acomp_req - asynchronous compression request
+ *
+ * @base:	Common attributes for async crypto requests
+ * @src:	Pointer to memory containing the input scatterlist buffer
+ * @dst:	Pointer to memory containing the output scatterlist buffer
+ * @src_len:	Length of input buffer
+ * @dst_len:	Length of output buffer
+ * @out_len:	Number of bytes produced by (de)compressor
+ * @__ctx:	Start of private context data
+ */
+struct acomp_req {
+	struct crypto_async_request base;
+	struct scatterlist *src;
+	struct scatterlist *dst;
+	unsigned int src_len;
+	unsigned int dst_len;
+	unsigned int out_len;
+	void *__ctx[] CRYPTO_MINALIGN_ATTR;
+};
+
+/**
+ * struct crypto_acomp - user-instantiated objects which encapsulate
+ * algorithms and core processing logic
+ *
+ * @compress:	Function performs a compress operation
+ * @decompress:	Function performs a de-compress operation
+ * @reqsize:	Request size required by algorithm implementation
+ * @base:	Common crypto API algorithm data structure
+ */
+struct crypto_acomp {
+	int (*compress)(struct acomp_req *req);
+	int (*decompress)(struct acomp_req *req);
+	unsigned int reqsize;
+	struct crypto_tfm base;
+};
+
+/**
+ * struct acomp_alg - async compression algorithm
+ *
+ * @compress:	Function performs a compress operation
+ * @decompress:	Function performs a de-compress operation
+ * @init:	Initialize the cryptographic transformation object.
+ *		This function is used to initialize the cryptographic
+ *		transformation object. This function is called only once at
+ *		the instantiation time, right after the transformation context
+ *		was allocated. In case the cryptographic hardware has some
+ *		special requirements which need to be handled by software, this
+ *		function shall check for the precise requirement of the
+ *		transformation and put any software fallbacks in place.
+ * @exit:	Deinitialize the cryptographic transformation object. This is a
+ *		counterpart to @init, used to remove various changes set in
+ *		@init.
+ *
+ * @base:	Common crypto API algorithm data structure
+ */
+struct acomp_alg {
+	int (*compress)(struct acomp_req *req);
+	int (*decompress)(struct acomp_req *req);
+	int (*init)(struct crypto_acomp *tfm);
+	void (*exit)(struct crypto_acomp *tfm);
+	struct crypto_alg base;
+};
+
+/**
+ * DOC: Asynchronous Compression API
+ *
+ * The Asynchronous Compression API is used with the algorithms of type
+ * CRYPTO_ALG_TYPE_ACOMPRESS (listed as type "acomp" in /proc/crypto)
+ */
+
+/**
+ * crypto_alloc_acompress() -- allocate ACOMPRESS tfm handle
+ * @alg_name: is the cra_name / name or cra_driver_name / driver name of the
+ *	      compression algorithm e.g. "deflate"
+ * @type: specifies the type of the algorithm
+ * @mask: specifies the mask for the algorithm
+ *
+ * Allocate a handle for compression algorithm. The returned struct
+ * crypto_acomp is the handle that is required for any subsequent
+ * API invocation for the compression operations.
+ *
+ * Return: allocated handle in case of success; IS_ERR() is true in case
+ *	   of an error, PTR_ERR() returns the error code.
+ */
+struct crypto_acomp *crypto_alloc_acomp(const char *alg_name, u32 type,
+					u32 mask);
+
+static inline struct crypto_tfm *crypto_acomp_tfm(struct crypto_acomp *tfm)
+{
+	return &tfm->base;
+}
+
+static inline struct crypto_acomp *crypto_acomp_cast(struct crypto_tfm *tfm)
+{
+	return (struct crypto_acomp *)tfm;
+}
+
+static inline void *crypto_acomp_ctx(struct crypto_acomp *tfm)
+{
+	return crypto_tfm_ctx(crypto_acomp_tfm(tfm));
+}
+
+static inline struct acomp_alg *__crypto_acomp_alg(struct crypto_alg *alg)
+{
+	return container_of(alg, struct acomp_alg, base);
+}
+
+static inline struct crypto_acomp *__crypto_acomp_tfm(
+	struct crypto_tfm *tfm)
+{
+	return container_of(tfm, struct crypto_acomp, base);
+}
+
+static inline struct acomp_alg *crypto_acomp_alg(
+	struct crypto_acomp *tfm)
+{
+	return __crypto_acomp_alg(crypto_acomp_tfm(tfm)->__crt_alg);
+}
+
+static inline unsigned int crypto_acomp_reqsize(struct crypto_acomp *tfm)
+{
+	return tfm->reqsize;
+}
+
+static inline void acomp_request_set_tfm(struct acomp_req *req,
+					 struct crypto_acomp *tfm)
+{
+	req->base.tfm = crypto_acomp_tfm(tfm);
+}
+
+static inline struct crypto_acomp *crypto_acomp_reqtfm(
+				struct acomp_req *req)
+{
+	return __crypto_acomp_tfm(req->base.tfm);
+}
+
+/**
+ * crypto_free_acomp() -- free ACOMPRESS tfm handle
+ *
+ * @tfm: ACOMPRESS tfm handle allocated with crypto_alloc_acompr()
+ */
+static inline void crypto_free_acomp(struct crypto_acomp *tfm)
+{
+	crypto_destroy_tfm(tfm, crypto_acomp_tfm(tfm));
+}
+
+static inline int crypto_has_acomp(const char *alg_name, u32 type, u32 mask)
+{
+	type &= ~CRYPTO_ALG_TYPE_MASK;
+	type |= CRYPTO_ALG_TYPE_ACOMPRESS;
+	mask |= CRYPTO_ALG_TYPE_MASK;
+
+	return crypto_has_alg(alg_name, type, mask);
+}
+
+/**
+ * acomp_request_alloc() -- allocates async compress request
+ *
+ * @tfm:	ACOMPRESS tfm handle allocated with crypto_alloc_acomp()
+ * @gfp:	allocation flags
+ *
+ * Return: allocated handle in case of success or NULL in case of an error.
+ */
+struct acomp_req *acomp_request_alloc(struct crypto_acomp *acomp,
+						gfp_t gfp);
+
+/**
+ * acomp_request_free() -- zeroize and free async compress request
+ *
+ * @req:	request to free
+ */
+void acomp_request_free(struct acomp_req *acomp);
+
+/**
+ * acomp_request_set_callback() -- Sets an asynchronous callback.
+ *
+ * Callback will be called when an asynchronous operation on a given
+ * request is finished.
+ *
+ * @req:	request that the callback will be set for
+ * @flgs:	specify for instance if the operation may backlog
+ * @cmlp:	callback which will be called
+ * @data:	private data used by the caller
+ */
+static inline void acomp_request_set_callback(struct acomp_req *req, u32 flgs,
+					crypto_completion_t cmpl, void *data)
+{
+	req->base.complete = cmpl;
+	req->base.data = data;
+	req->base.flags = flgs;
+}
+
+/**
+ * acomp_request_set_comp() -- Sets reqest parameters
+ *
+ * Sets parameters required by acomp operation
+ *
+ * @req:	async compress request
+ * @src:	ptr to input buffer list
+ * @dst:	ptr to output buffer list
+ * @src_len:	size of the input buffer
+ * @dst_len:	size of the output buffer
+ * @result:	(de)compression result returned by compressor
+ */
+static inline void acomp_request_set_comp(struct acomp_req *req,
+					  struct scatterlist *src,
+					  struct scatterlist *dst,
+					  unsigned int src_len,
+					  unsigned int dst_len)
+{
+	req->src = src;
+	req->dst = dst;
+	req->src_len = src_len;
+	req->dst_len = dst_len;
+	req->out_len = 0;
+}
+
+/**
+ * crypto_acomp_compress() -- Invoke async compress operation
+ *
+ * Function invokes the async compress operation
+ *
+ * @req:	async compress request
+ *
+ * Return: zero on success; error code in case of error
+ */
+static inline int crypto_acomp_compress(struct acomp_req *req)
+{
+	struct crypto_acomp *tfm = crypto_acomp_reqtfm(req);
+
+	return tfm->compress(req);
+}
+
+/**
+ * crypto_acomp_decompress() -- Invoke async decompress operation
+ *
+ * Function invokes the async decompress operation
+ *
+ * @req:	async compress request
+ *
+ * Return: zero on success; error code in case of error
+ */
+static inline int crypto_acomp_decompress(struct acomp_req *req)
+{
+	struct crypto_acomp *tfm = crypto_acomp_reqtfm(req);
+
+	return tfm->decompress(req);
+}
+
+extern int crypto_register_acomp(struct acomp_alg *alg);
+extern int crypto_unregister_acomp(struct acomp_alg *alg);
 #endif
diff --git a/include/crypto/internal/compress.h b/include/crypto/internal/compress.h
new file mode 100644
index 0000000..088bc5b
--- /dev/null
+++ b/include/crypto/internal/compress.h
@@ -0,0 +1,4 @@ 
+extern int crypto_init_scomp_ops_async(struct crypto_tfm *tfm);
+extern struct acomp_req *
+crypto_scomp_acomp_request_alloc(struct crypto_acomp *tfm, gfp_t gfp);
+extern void crypto_scomp_acomp_request_free(struct acomp_req *req);
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index ba73c18..ccd1d32 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -55,9 +55,11 @@ 
 #define CRYPTO_ALG_TYPE_RNG		0x0000000c
 #define CRYPTO_ALG_TYPE_AKCIPHER	0x0000000d
 #define CRYPTO_ALG_TYPE_SCOMPRESS	0x0000000e
+#define CRYPTO_ALG_TYPE_ACOMPRESS	0x0000000f
 
 #define CRYPTO_ALG_TYPE_HASH_MASK	0x0000000e
 #define CRYPTO_ALG_TYPE_AHASH_MASK	0x0000000c
+#define CRYPTO_ALG_TYPE_ACOMPRESS_MASK	0x0000000e
 #define CRYPTO_ALG_TYPE_BLKCIPHER_MASK	0x0000000c
 
 #define CRYPTO_ALG_LARVAL		0x00000010