[RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial write

[RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial write

[Minchan Kim]

Now zram allocates new page with GFP_KERNEL in zram I/O path
if IO is partial. Unfortunately, It may cuase deadlock with
reclaim path so this patch solves the problem.

Cc: stable@vger.kernel.org
Cc: Jerome Marchand <jmarchan@redhat.com>
Acked-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
 drivers/staging/zram/zram_drv.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 61fb8f1..b285b3a 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -220,7 +220,7 @@ static int zram_bvec_read(struct zram *zram, struct bio_vec *bvec,
 	user_mem = kmap_atomic(page);
 	if (is_partial_io(bvec))
 		/* Use  a temporary buffer to decompress the page */
-		uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
+		uncmem = kmalloc(PAGE_SIZE, GFP_ATOMIC);
 	else
 		uncmem = user_mem;
 
@@ -268,7 +268,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index,
 		 * This is a partial IO. We need to read the full page
 		 * before to write the changes.
 		 */
-		uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
+		uncmem = kmalloc(PAGE_SIZE, GFP_NOIO);
 		if (!uncmem) {
 			pr_info("Error allocating temp memory!\n");
 			ret = -ENOMEM;
-- 
1.7.9.5

Re: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial write

[Pekka Enberg]

On Mon, Jan 28, 2013 at 2:38 AM, Minchan Kim <minchan@kernel.org> wrote:
> Now zram allocates new page with GFP_KERNEL in zram I/O path
> if IO is partial. Unfortunately, It may cuase deadlock with

s/cuase/cause/g

> reclaim path so this patch solves the problem.

It'd be nice to know about the problem in more detail. I'm also
curious on why you decided on GFP_ATOMIC for the read path and
GFP_NOIO in the write path.

>
> Cc: stable@vger.kernel.org
> Cc: Jerome Marchand <jmarchan@redhat.com>
> Acked-by: Nitin Gupta <ngupta@vflare.org>
> Signed-off-by: Minchan Kim <minchan@kernel.org>
> ---
>  drivers/staging/zram/zram_drv.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
> index 61fb8f1..b285b3a 100644
> --- a/drivers/staging/zram/zram_drv.c
> +++ b/drivers/staging/zram/zram_drv.c
> @@ -220,7 +220,7 @@ static int zram_bvec_read(struct zram *zram, struct bio_vec *bvec,
>         user_mem = kmap_atomic(page);
>         if (is_partial_io(bvec))
>                 /* Use  a temporary buffer to decompress the page */
> -               uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
> +               uncmem = kmalloc(PAGE_SIZE, GFP_ATOMIC);
>         else
>                 uncmem = user_mem;
>
> @@ -268,7 +268,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index,
>                  * This is a partial IO. We need to read the full page
>                  * before to write the changes.
>                  */
> -               uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
> +               uncmem = kmalloc(PAGE_SIZE, GFP_NOIO);
>                 if (!uncmem) {
>                         pr_info("Error allocating temp memory!\n");
>                         ret = -ENOMEM;
> --
> 1.7.9.5
>
> --
> 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>

Re: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial write

[Jerome Marchand]

On 01/28/2013 08:16 AM, Pekka Enberg wrote:
> On Mon, Jan 28, 2013 at 2:38 AM, Minchan Kim <minchan@kernel.org> wrote:
>> Now zram allocates new page with GFP_KERNEL in zram I/O path
>> if IO is partial. Unfortunately, It may cuase deadlock with
> 
> s/cuase/cause/g
> 
>> reclaim path so this patch solves the problem.
> 
> It'd be nice to know about the problem in more detail. I'm also
> curious on why you decided on GFP_ATOMIC for the read path and
> GFP_NOIO in the write path.

This is because we're holding a kmap_atomic page in the read path.

Jerome

> 
>>
>> Cc: stable@vger.kernel.org
>> Cc: Jerome Marchand <jmarchan@redhat.com>
>> Acked-by: Nitin Gupta <ngupta@vflare.org>
>> Signed-off-by: Minchan Kim <minchan@kernel.org>
>> ---
>>  drivers/staging/zram/zram_drv.c |    4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
>> index 61fb8f1..b285b3a 100644
>> --- a/drivers/staging/zram/zram_drv.c
>> +++ b/drivers/staging/zram/zram_drv.c
>> @@ -220,7 +220,7 @@ static int zram_bvec_read(struct zram *zram, struct bio_vec *bvec,
>>         user_mem = kmap_atomic(page);
>>         if (is_partial_io(bvec))
>>                 /* Use  a temporary buffer to decompress the page */
>> -               uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
>> +               uncmem = kmalloc(PAGE_SIZE, GFP_ATOMIC);
>>         else
>>                 uncmem = user_mem;
>>
>> @@ -268,7 +268,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index,
>>                  * This is a partial IO. We need to read the full page
>>                  * before to write the changes.
>>                  */
>> -               uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
>> +               uncmem = kmalloc(PAGE_SIZE, GFP_NOIO);
>>                 if (!uncmem) {
>>                         pr_info("Error allocating temp memory!\n");
>>                         ret = -ENOMEM;
>> --
>> 1.7.9.5
>>
>> --
>> 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>

Re: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial write

[Pekka Enberg]

On Mon, Jan 28, 2013 at 1:24 PM, Jerome Marchand <jmarchan@redhat.com> wrote:
> On 01/28/2013 08:16 AM, Pekka Enberg wrote:
>> On Mon, Jan 28, 2013 at 2:38 AM, Minchan Kim <minchan@kernel.org> wrote:
>>> Now zram allocates new page with GFP_KERNEL in zram I/O path
>>> if IO is partial. Unfortunately, It may cuase deadlock with
>>
>> s/cuase/cause/g
>>
>>> reclaim path so this patch solves the problem.
>>
>> It'd be nice to know about the problem in more detail. I'm also
>> curious on why you decided on GFP_ATOMIC for the read path and
>> GFP_NOIO in the write path.
>
> This is because we're holding a kmap_atomic page in the read path.

Okay, so that's about partial *reads* and not even mentioned in the
changelog, no?

AFAICT, you could rearrange the code in zram_bvec_read() as follows:

        if (is_partial_io(bvec))
                /* Use  a temporary buffer to decompress the page */
                uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
        else {
                uncmem = user_mem = kmap_atomic(page);
        }

and avoid the GFP_ATOMIC allocation.

Re: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial write

[Jerome Marchand]

On 01/28/2013 02:26 PM, Pekka Enberg wrote:
> On Mon, Jan 28, 2013 at 1:24 PM, Jerome Marchand <jmarchan@redhat.com> wrote:
>> On 01/28/2013 08:16 AM, Pekka Enberg wrote:
>>> On Mon, Jan 28, 2013 at 2:38 AM, Minchan Kim <minchan@kernel.org> wrote:
>>>> Now zram allocates new page with GFP_KERNEL in zram I/O path
>>>> if IO is partial. Unfortunately, It may cuase deadlock with
>>>
>>> s/cuase/cause/g
>>>
>>>> reclaim path so this patch solves the problem.
>>>
>>> It'd be nice to know about the problem in more detail. I'm also
>>> curious on why you decided on GFP_ATOMIC for the read path and
>>> GFP_NOIO in the write path.
>>
>> This is because we're holding a kmap_atomic page in the read path.
> 
> Okay, so that's about partial *reads* and not even mentioned in the
> changelog, no?
> 
> AFAICT, you could rearrange the code in zram_bvec_read() as follows:
> 
>         if (is_partial_io(bvec))
>                 /* Use  a temporary buffer to decompress the page */
>                 uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
>         else {
>                 uncmem = user_mem = kmap_atomic(page);
>         }
> 
> and avoid the GFP_ATOMIC allocation.
> 

user_mem still has to be mapped in case of partial I/O too. But the
temporary buffer allocation could happen before. The allocation still
would need to be GFP_NOIO to avoid possible deadlocks.

Anyhow, the commit message could definitely be more explicit.

Regards,
Jerome

Re: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial write

[Minchan Kim]

On Mon, Jan 28, 2013 at 09:16:35AM +0200, Pekka Enberg wrote:
> On Mon, Jan 28, 2013 at 2:38 AM, Minchan Kim <minchan@kernel.org> wrote:
> > Now zram allocates new page with GFP_KERNEL in zram I/O path
> > if IO is partial. Unfortunately, It may cuase deadlock with
> 
> s/cuase/cause/g

Thanks!

> 
> > reclaim path so this patch solves the problem.
> 
> It'd be nice to know about the problem in more detail. I'm also
> curious on why you decided on GFP_ATOMIC for the read path and
> GFP_NOIO in the write path.

In read path, we called kmap_atomic.

How about this?
------------------------- >8 -------------------------------

>From 9f8756ae0b0f2819f93cb94dcd38da372843aa12 Mon Sep 17 00:00:00 2001
From: Minchan Kim <minchan@kernel.org>
Date: Mon, 21 Jan 2013 13:58:52 +0900
Subject: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial read/write

Now zram allocates new page with GFP_KERNEL in zram I/O path
if IO is partial. Unfortunately, It may cause deadlock with
reclaim path like below.

write_page from fs
fs_lock
allocation(GFP_KERNEL)
reclaim
pageout
				write_page from fs
				fs_lock <-- deadlock

This patch fixes it by using GFP_ATOMIC and GFP_NOIO.
In read path, we called kmap_atomic so that we need GFP_ATOMIC
while we need GFP_NOIO in write path.

Cc: stable@vger.kernel.org
Cc: Jerome Marchand <jmarchan@redhat.com>
Acked-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
We could use GFP_IO instead of GFP_ATOMIC in zram_bvec_read with
some modification related to buffer allocation in case of partial IO.
But it needs more churn and prevent merge this patch into stable
if we should send this to stable so I'd like to keep it as simple
as possbile. GFP_IO usage could be separate patch after we merge it.
Thanks.
 drivers/staging/zram/zram_drv.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 61fb8f1..b285b3a 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -220,7 +220,7 @@ static int zram_bvec_read(struct zram *zram, struct bio_vec *bvec,
 	user_mem = kmap_atomic(page);
 	if (is_partial_io(bvec))
 		/* Use  a temporary buffer to decompress the page */
-		uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
+		uncmem = kmalloc(PAGE_SIZE, GFP_ATOMIC);
 	else
 		uncmem = user_mem;
 
@@ -268,7 +268,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index,
 		 * This is a partial IO. We need to read the full page
 		 * before to write the changes.
 		 */
-		uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
+		uncmem = kmalloc(PAGE_SIZE, GFP_NOIO);
 		if (!uncmem) {
 			pr_info("Error allocating temp memory!\n");
 			ret = -ENOMEM;
-- 
1.7.9.5

-- 
Kind regards,
Minchan Kim

Re: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial write

[Pekka Enberg]

On Tue, Jan 29, 2013 at 1:21 AM, Minchan Kim <minchan@kernel.org> wrote:
> How about this?
> ------------------------- >8 -------------------------------
> 
> From 9f8756ae0b0f2819f93cb94dcd38da372843aa12 Mon Sep 17 00:00:00 2001
> From: Minchan Kim <minchan@kernel.org>
> Date: Mon, 21 Jan 2013 13:58:52 +0900
> Subject: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial read/write
> 
> Now zram allocates new page with GFP_KERNEL in zram I/O path
> if IO is partial. Unfortunately, It may cause deadlock with
> reclaim path like below.
> 
> write_page from fs
> fs_lock
> allocation(GFP_KERNEL)
> reclaim
> pageout
> 				write_page from fs
> 				fs_lock <-- deadlock
> 
> This patch fixes it by using GFP_ATOMIC and GFP_NOIO.
> In read path, we called kmap_atomic so that we need GFP_ATOMIC
> while we need GFP_NOIO in write path.

The patch description makes sense now. Thanks!

On Tue, Jan 29, 2013 at 1:21 AM, Minchan Kim <minchan@kernel.org> wrote:
> We could use GFP_IO instead of GFP_ATOMIC in zram_bvec_read with
> some modification related to buffer allocation in case of partial IO.
> But it needs more churn and prevent merge this patch into stable
> if we should send this to stable so I'd like to keep it as simple
> as possbile. GFP_IO usage could be separate patch after we merge it.

I don't see why something like below couldn't be merged for stable.
Going for GFP_ATOMIC might seem like the simplest thing to go for but
usually bites you in the end.

			Pekka

------------------------- >8 -------------------------------

>From 936a12b423c58542628d6fd683e859f752eb3d41 Mon Sep 17 00:00:00 2001
From: Minchan Kim <minchan@kernel.org>
Date: Mon, 21 Jan 2013 13:58:52 +0900
Subject: [PATCH] zram: Fix deadlock bug in partial read/write

Now zram allocates new page with GFP_KERNEL in zram I/O path
if IO is partial. Unfortunately, It may cause deadlock with
reclaim path like below.

write_page from fs
fs_lock
allocation(GFP_KERNEL)
reclaim
pageout
				write_page from fs
				fs_lock <-- deadlock

This patch fixes it by using GFP_NOIO.  In read path, we
reorganize code flow so that kmap_atomic is called after the
GFP_NOIO allocation.

Cc: stable@vger.kernel.org
Cc: Jerome Marchand <jmarchan@redhat.com>
Acked-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Minchan Kim <minchan@kernel.org>
[ penberg@kernel.org: don't use GFP_ATOMIC ]
Signed-off-by: Pekka Enberg <penberg@kernel.org>
---
 drivers/staging/zram/zram_drv.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index f2a73bd..071e058 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -228,11 +228,12 @@ static int zram_bvec_read(struct zram *zram, struct bio_vec *bvec,
 		return 0;
 	}
 
-	user_mem = kmap_atomic(page);
 	if (is_partial_io(bvec))
 		/* Use  a temporary buffer to decompress the page */
-		uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
-	else
+		uncmem = kmalloc(PAGE_SIZE, GFP_NOIO);
+
+	user_mem = kmap_atomic(page);
+	if (!is_partial_io(bvec))
 		uncmem = user_mem;
 
 	if (!uncmem) {
@@ -279,7 +280,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index,
 		 * This is a partial IO. We need to read the full page
 		 * before to write the changes.
 		 */
-		uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
+		uncmem = kmalloc(PAGE_SIZE, GFP_NOIO);
 		if (!uncmem) {
 			pr_info("Error allocating temp memory!\n");
 			ret = -ENOMEM;
-- 
1.7.11.7

Re: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial write

[Minchan Kim]

On Tue, Jan 29, 2013 at 09:11:08AM +0200, Pekka Enberg wrote:
> On Tue, Jan 29, 2013 at 1:21 AM, Minchan Kim <minchan@kernel.org> wrote:
> > How about this?
> > ------------------------- >8 -------------------------------
> > 
> > From 9f8756ae0b0f2819f93cb94dcd38da372843aa12 Mon Sep 17 00:00:00 2001
> > From: Minchan Kim <minchan@kernel.org>
> > Date: Mon, 21 Jan 2013 13:58:52 +0900
> > Subject: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial read/write
> > 
> > Now zram allocates new page with GFP_KERNEL in zram I/O path
> > if IO is partial. Unfortunately, It may cause deadlock with
> > reclaim path like below.
> > 
> > write_page from fs
> > fs_lock
> > allocation(GFP_KERNEL)
> > reclaim
> > pageout
> > 				write_page from fs
> > 				fs_lock <-- deadlock
> > 
> > This patch fixes it by using GFP_ATOMIC and GFP_NOIO.
> > In read path, we called kmap_atomic so that we need GFP_ATOMIC
> > while we need GFP_NOIO in write path.
> 
> The patch description makes sense now. Thanks!
> 
> On Tue, Jan 29, 2013 at 1:21 AM, Minchan Kim <minchan@kernel.org> wrote:
> > We could use GFP_IO instead of GFP_ATOMIC in zram_bvec_read with
> > some modification related to buffer allocation in case of partial IO.
> > But it needs more churn and prevent merge this patch into stable
> > if we should send this to stable so I'd like to keep it as simple
> > as possbile. GFP_IO usage could be separate patch after we merge it.
> 
> I don't see why something like below couldn't be merged for stable.
> Going for GFP_ATOMIC might seem like the simplest thing to go for but
> usually bites you in the end.

Looks good to me. I will resend it.
Thanks, Pekka.

> 
> 			Pekka
> 
> ------------------------- >8 -------------------------------
> 
> >From 936a12b423c58542628d6fd683e859f752eb3d41 Mon Sep 17 00:00:00 2001
> From: Minchan Kim <minchan@kernel.org>
> Date: Mon, 21 Jan 2013 13:58:52 +0900
> Subject: [PATCH] zram: Fix deadlock bug in partial read/write
> 
> Now zram allocates new page with GFP_KERNEL in zram I/O path
> if IO is partial. Unfortunately, It may cause deadlock with
> reclaim path like below.
> 
> write_page from fs
> fs_lock
> allocation(GFP_KERNEL)
> reclaim
> pageout
> 				write_page from fs
> 				fs_lock <-- deadlock
> 
> This patch fixes it by using GFP_NOIO.  In read path, we
> reorganize code flow so that kmap_atomic is called after the
> GFP_NOIO allocation.
> 
> Cc: stable@vger.kernel.org
> Cc: Jerome Marchand <jmarchan@redhat.com>
> Acked-by: Nitin Gupta <ngupta@vflare.org>
> Signed-off-by: Minchan Kim <minchan@kernel.org>
> [ penberg@kernel.org: don't use GFP_ATOMIC ]
> Signed-off-by: Pekka Enberg <penberg@kernel.org>
> ---
>  drivers/staging/zram/zram_drv.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
> index f2a73bd..071e058 100644
> --- a/drivers/staging/zram/zram_drv.c
> +++ b/drivers/staging/zram/zram_drv.c
> @@ -228,11 +228,12 @@ static int zram_bvec_read(struct zram *zram, struct bio_vec *bvec,
>  		return 0;
>  	}
>  
> -	user_mem = kmap_atomic(page);
>  	if (is_partial_io(bvec))
>  		/* Use  a temporary buffer to decompress the page */
> -		uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
> -	else
> +		uncmem = kmalloc(PAGE_SIZE, GFP_NOIO);
> +
> +	user_mem = kmap_atomic(page);
> +	if (!is_partial_io(bvec))
>  		uncmem = user_mem;
>  
>  	if (!uncmem) {
> @@ -279,7 +280,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index,
>  		 * This is a partial IO. We need to read the full page
>  		 * before to write the changes.
>  		 */
> -		uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
> +		uncmem = kmalloc(PAGE_SIZE, GFP_NOIO);
>  		if (!uncmem) {
>  			pr_info("Error allocating temp memory!\n");
>  			ret = -ENOMEM;
> -- 
> 1.7.11.7
> 
> --
> 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>

-- 
Kind regards,
Minchan Kim

Re: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial write

[Greg Kroah-Hartman]

On Mon, Jan 28, 2013 at 09:38:23AM +0900, Minchan Kim wrote:
> Now zram allocates new page with GFP_KERNEL in zram I/O path
> if IO is partial. Unfortunately, It may cuase deadlock with
> reclaim path so this patch solves the problem.
> 
> Cc: stable@vger.kernel.org
> Cc: Jerome Marchand <jmarchan@redhat.com>
> Acked-by: Nitin Gupta <ngupta@vflare.org>
> Signed-off-by: Minchan Kim <minchan@kernel.org>
> ---
>  drivers/staging/zram/zram_drv.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Due to the discussion on this series, I don't know what patch to apply,
so care to do a v6 of this with the patches that everyone has finally
agreed on?

I'm dropping these from my to-apply queue now.

thanks,

greg k-h

Re: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial write

[Minchan Kim]

Hi Greg,

On Tue, Jan 29, 2013 at 11:20:06PM -0500, Greg Kroah-Hartman wrote:
> On Mon, Jan 28, 2013 at 09:38:23AM +0900, Minchan Kim wrote:
> > Now zram allocates new page with GFP_KERNEL in zram I/O path
> > if IO is partial. Unfortunately, It may cuase deadlock with
> > reclaim path so this patch solves the problem.
> > 
> > Cc: stable@vger.kernel.org
> > Cc: Jerome Marchand <jmarchan@redhat.com>
> > Acked-by: Nitin Gupta <ngupta@vflare.org>
> > Signed-off-by: Minchan Kim <minchan@kernel.org>
> > ---
> >  drivers/staging/zram/zram_drv.c |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Due to the discussion on this series, I don't know what patch to apply,
> so care to do a v6 of this with the patches that everyone has finally
> agreed on?

I already sent v6.
https://lkml.org/lkml/2013/1/29/680

Thanks.

-- 
Kind regards,
Minchan Kim

Re: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial write

[Minchan Kim]

On Wed, Jan 30, 2013 at 05:21:12PM +0900, Minchan Kim wrote:
> Hi Greg,
> 
> On Tue, Jan 29, 2013 at 11:20:06PM -0500, Greg Kroah-Hartman wrote:
> > On Mon, Jan 28, 2013 at 09:38:23AM +0900, Minchan Kim wrote:
> > > Now zram allocates new page with GFP_KERNEL in zram I/O path
> > > if IO is partial. Unfortunately, It may cuase deadlock with
> > > reclaim path so this patch solves the problem.
> > > 
> > > Cc: stable@vger.kernel.org
> > > Cc: Jerome Marchand <jmarchan@redhat.com>
> > > Acked-by: Nitin Gupta <ngupta@vflare.org>
> > > Signed-off-by: Minchan Kim <minchan@kernel.org>
> > > ---
> > >  drivers/staging/zram/zram_drv.c |    4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > Due to the discussion on this series, I don't know what patch to apply,
> > so care to do a v6 of this with the patches that everyone has finally
> > agreed on?
> 
> I already sent v6.
> https://lkml.org/lkml/2013/1/29/680

Greg, If you have a trouble to merge it, let me know it.
Will resend it when linux-next comes in.

Thanks.
-- 
Kind regards,
Minchan Kim