On 01/28/2013 02:26 PM, Pekka Enberg wrote: > On Mon, Jan 28, 2013 at 1:24 PM, Jerome Marchand <jmarc...@redhat.com> wrote: >> On 01/28/2013 08:16 AM, Pekka Enberg wrote: >>> On Mon, Jan 28, 2013 at 2:38 AM, Minchan Kim <minc...@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 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html