linux-kernel - Re: [PATCH v2 4/4] mm/zswap: use GFP_NOIO instead of GFP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 9 Sep 2013 11:47:50 -0500
From:	Seth Jennings <sjenning@...ux.vnet.ibm.com>
To:	Weijie Yang <weijie.yang@...sung.com>
Cc:	minchan@...nel.org, bob.liu@...cle.com, weijie.yang.kh@...il.com,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/4] mm/zswap: use GFP_NOIO instead of GFP_KERNEL

On Fri, Sep 06, 2013 at 01:16:45PM +0800, Weijie Yang wrote:
> To avoid zswap store and reclaim functions called recursively,
> use GFP_NOIO instead of GFP_KERNEL
> 
> Signed-off-by: Weijie Yang <weijie.yang@...sung.com>

I agree with Bob to some degree that GFP_NOIO is a broadsword here.
Ideally, we'd like to continue allowing writeback of dirty file pages
and the like.  However, I don't agree that a mutex is the way to do
this.

My first thought was to use the PF_MEMALLOC task flag, but it is already
set for kswapd and any task doing direct reclaim.  A new task flag would
work but I'm not sure how acceptable that would be.

In the meantime, this does do away with the possibility of very deep
recursion between the store and reclaim paths.

Acked-by: Seth Jennings <sjenning@...ux.vnet.ibm.com>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/