linux-kernel - Re: [PATCH v2 3/3] zram: pass gfp from zcomp frontend to backend

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:	Wed, 25 Nov 2015 21:46:47 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:	Minchan Kim <minchan@...nel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Kyeongdon Kim <kyeongdon.kim@....com>
Subject: Re: [PATCH v2 3/3] zram: pass gfp from zcomp frontend to backend

On (11/25/15 14:51), Minchan Kim wrote:
[..]
> +		/*
> +		 * This function could be called in swapout/fs write path
> +		 * so we couldn't use GFP_FS|IO. And it assumes we already
> +		 * have at least one stream in zram initialization so we
> +		 * don't do best effort to allocate more stream in here.
> +		 * A default stream will work well without further multiple
> +		 * stream. That's why we use __GFP_NORETRY|NOWARN|NOMEMALLOC.
> +		 */
> +		zstrm = zcomp_strm_alloc(comp, GFP_NOIO|__GFP_NORETRY|
> +					__GFP_NOWARN|__GFP_NOMEMALLOC);
[..]

I think that applying 3/3 before 2/3 will be a simpler (and probably a better)
thing to do. We fitst extend zcomp interface and pass flags (without any
functional change) and then extend the flags and introduce vmalloc fallback.

So we don't have to add comments to lz4/lzo backend that are getting (re-)moved
in the very next commit.

I will send swapped 2 and 3 patches shortly (I didn't change commit
messages and SoBs). Please take a look.

> -	/*
> -	 * This function could be called in swapout/fs write path
> -	 * so we couldn't use GFP_FS|IO. And it assumes we already
> -	 * have at least one stream in zram initialization so we
> -	 * don't do best effort to allocate more stream in here.
> -	 * A default stream will work well without further multiple
> -	 * stream. That's why we use  __GFP_NORETRY|NOWARN|NOMEMALLOC.
> -	 */
> -	ret = kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO|__GFP_NORETRY|
> -					__GFP_NOWARN|__GFP_NOMEMALLOC);
> +	ret = kmalloc(LZ4_MEM_COMPRESS, flags);
>  	if (!ret)
> -		ret = __vmalloc(LZ4_MEM_COMPRESS, GFP_NOIO|__GFP_NORETRY|
> -						__GFP_NOWARN|__GFP_NOMEMALLOC|
> -						__GFP_ZERO,
> -						PAGE_KERNEL);
> +		ret = __vmalloc(LZ4_MEM_COMPRESS, flags, PAGE_KERNEL);
[..]

__vmalloc() is still missing __GFP_HIGHMEM

> -	/*
> -	 * This function could be called in swapout/fs write path
> -	 * so we couldn't use GFP_FS|IO. And it assumes we already
> -	 * have at least one stream in zram initialization so we
> -	 * don't do best effort to allocate more stream in here.
> -	 * A default stream will work well without further multiple
> -	 * stream. That's why we use  __GFP_NORETRY|NOWARN|NOMEMALLOC.
> -	 */
> -	ret = kzalloc(LZO1X_MEM_COMPRESS, GFP_NOIO|__GFP_NORETRY|
> -					__GFP_NOWARN|__GFP_NOMEMALLOC);
> +
> +	ret = kmalloc(LZO1X_MEM_COMPRESS, flags);
>  	if (!ret)
> -		ret = __vmalloc(LZO1X_MEM_COMPRESS, GFP_NOIO|__GFP_NORETRY|
> -						__GFP_NOWARN|__GFP_NOMEMALLOC|
> -						__GFP_ZERO,
> -						PAGE_KERNEL);
> +		ret = __vmalloc(LZO1X_MEM_COMPRESS, flags, PAGE_KERNEL);

ditto.

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