lkml.org 
[lkml]   [2017]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm/zswap: fix potential deadlock in zswap_frontswap_store()
On Mon 03-04-17 14:57:11, Andrey Ryabinin wrote:
> On 04/03/2017 11:47 AM, Michal Hocko wrote:
> > On Fri 31-03-17 10:00:30, Shakeel Butt wrote:
[...]
> >>> @@ -1017,9 +1018,7 @@ static int zswap_frontswap_store(unsigned type, pgoff_t offset,
> >>>
> >>> /* store */
> >>> len = dlen + sizeof(struct zswap_header);
> >>> - ret = zpool_malloc(entry->pool->zpool, len,
> >>> - __GFP_NORETRY | __GFP_NOWARN | __GFP_KSWAPD_RECLAIM,
> >>> - &handle);
> >>> + ret = zpool_malloc(entry->pool->zpool, len, gfp, &handle);
> >
> > and here we used to do GFP_NOWAIT alternative already. What is going on
> > here?
>
>
> I suspect that there was no particular reason to assemble this
> custom set of gfp flags. This code probably should have been using
> GFP_NOWAIT|__GFP_NOWARN from the very beginning.

Or just use GFP_KERNEL with a comment that this is called from the
reclaim context and as such is properly addressed at the page allocator
layer. One reason why this makes more sense than GFP_NOWAIT is that
this is easier to follow. When you see GFP_NOWAIT then you usually
expect a best efford opportunistic allocation attempt (especially with
__GFP_NOWARN) which is not the case here because this paths gets a full
memory reserves access. If this is not intentional then use GFP_NOWAIT |
__GFP_NOMEMALLOC | __GFP_NOWARN.

--
Michal Hocko
SUSE Labs

\
 
 \ /
  Last update: 2017-04-03 14:30    [W:1.032 / U:0.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site