linux-kernel - Re: [PATCH RESEND] mm: don't zero ballooned pages

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: <20170803125409.GT12521@dhcp22.suse.cz>
Date:   Thu, 3 Aug 2017 14:54:09 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Wei Wang <wei.w.wang@...el.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        virtualization@...ts.linux-foundation.org, mst@...hat.com,
        zhenwei.pi@...runcloud.com, akpm@...ux-foundation.org,
        dave.hansen@...el.com, mawilcox@...rosoft.com
Subject: Re: [PATCH RESEND] mm: don't zero ballooned pages

On Thu 03-08-17 19:59:17, Wei Wang wrote:
> This patch is a revert of 'commit bb01b64cfab7 ("mm/balloon_compaction.c:
> enqueue zero page to balloon device")'
> 
> Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
> shouldn't be given to the host ksmd to scan.

I find MADV_DONTNEED reference still quite confusing. What do you think
about the following wording instead:
"
Zeroying ballon pages is rather time consuming, especially when a lot of
pages are in flight. E.g. 7GB worth of ballooned memory takes 2.8s with
__GFP_ZERO while it takes ~491ms without it. The original commit argued
that zeroying will help ksmd to merge these pages on the host but this
argument is assuming that the host actually marks balloon pages for ksm
which is not universally true. So we pay performance penalty for
something that even might not be used in the end which is wrong. The
host can zero out pages on its own when there is a need.
"

> Therefore, it is not
> necessary to zero ballooned pages, which is very time consuming when
> the page amount is large. The ongoing fast balloon tests show that the
> time to balloon 7G pages is increased from ~491ms to 2.8 seconds with
> __GFP_ZERO added. So, this patch removes the flag.

The only reason why unconditional zeroying makes some sense is the
data leak protection (guest doesn't want to leak potentially sensitive
data to a malicious guest). I am not sure such a thread applies here
though.

> Signed-off-by: Wei Wang <wei.w.wang@...el.com>
> Cc: Michal Hocko <mhocko@...nel.org>
> Cc: Michael S. Tsirkin <mst@...hat.com>

other than that
Acked-by: Michal Hocko <mhocko@...e.com>

> ---
>  mm/balloon_compaction.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
> index 9075aa5..b06d9fe 100644
> --- a/mm/balloon_compaction.c
> +++ b/mm/balloon_compaction.c
> @@ -24,7 +24,7 @@ struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info)
>  {
>  	unsigned long flags;
>  	struct page *page = alloc_page(balloon_mapping_gfp_mask() |
> -				__GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_ZERO);
> +				       __GFP_NOMEMALLOC | __GFP_NORETRY);
>  	if (!page)
>  		return NULL;
>  
> -- 
> 2.7.4

-- 
Michal Hocko
SUSE Labs