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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 16 Sep 2013 17:16:52 +0800
From:	Weijie Yang <weijie.yang.kh@...il.com>
To:	Seth Jennings <sjenning@...ux.vnet.ibm.com>
Cc:	Weijie Yang <weijie.yang@...sung.com>, minchan@...nel.org,
	bob.liu@...cle.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 Tue, Sep 10, 2013 at 12:47 AM, Seth Jennings
<sjenning@...ux.vnet.ibm.com> wrote:
> 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.

as GFP_NOIO is controversial and not the most appropriate method,
I will keep GFP_KERNEL flag until we find a better way to resolve
this problem.

> 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/