linux-kernel - Re: [PATCH v3] zram: try vmalloc() after kmalloc()

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151124010622.GB705@swordfish>
Date:	Tue, 24 Nov 2015 10:06:22 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:	Minchan Kim <minchan@...nel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Kyeongdon Kim <kyeongdon.kim@....com>, ngupta@...are.org,
	sergey.senozhatsky.work@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] zram: try vmalloc() after kmalloc()

On (11/24/15 09:35), Minchan Kim wrote:
[..]
> > We can use __GFP_RECLAIM (used to be __GFP_WAIT).  That permits the
> > allocation to wait for in-flight IO to complete and to reclaim clean
> > pagecache.
> 
> Generally, you're right but in case of zram, it would be unfortunate.
> 
> It would be void *most of time* because it is called in reclaim context
> and reclaim path bails out to avoid recursion of direct reclaim
> by PF_MEMALLOC without trying reclaim.
> However, the reason I said *most of time* is we has another context
> the funcion could be called.
> 
>         "disksize_store"->zcomp_create
> 
> In the place, we should make sure the successful allocation to work
> zram at least so that path should use another gfp.
> I will work for that.

Hm... is it really worth it? passing a bool to zcomp_strm_alloc() (so
it can decide what gfp flags to use) or gfp flags directly is just a
bit complicated. what's the problem with GFP_NOIO (__GFP_RECLAIM) in
the first place (sorry if I'm missing something terribly obvious)?

alternatively, we can just remove the 'dynamic' streams allocation part
and allocate all of the streams via sysfs store path only.

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