linux-kernel - Re: [PATCH -mm] mm: Clear to access sub-page last when clearing huge page

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]

Message-ID: <alpine.DEB.2.20.1708071343030.19915@nuc-kabylake>
Date:   Mon, 7 Aug 2017 13:46:37 -0500 (CDT)
From:   Christopher Lameter <cl@...ux.com>
To:     "Huang, Ying" <ying.huang@...el.com>
cc:     Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Andrea Arcangeli <aarcange@...hat.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Nadia Yvette Chambers <nyc@...omorphy.com>,
        Michal Hocko <mhocko@...e.com>, Jan Kara <jack@...e.cz>,
        Matthew Wilcox <willy@...ux.intel.com>,
        Hugh Dickins <hughd@...gle.com>,
        Minchan Kim <minchan@...nel.org>, Shaohua Li <shli@...com>
Subject: Re: [PATCH -mm] mm: Clear to access sub-page last when clearing huge
 page

On Mon, 7 Aug 2017, Huang, Ying wrote:

> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4374,9 +4374,31 @@ void clear_huge_page(struct page *page,
>  	}
>
>  	might_sleep();
> -	for (i = 0; i < pages_per_huge_page; i++) {
> +	VM_BUG_ON(clamp(addr_hint, addr, addr +
> +			(pages_per_huge_page << PAGE_SHIFT)) != addr_hint);
> +	n = (addr_hint - addr) / PAGE_SIZE;
> +	if (2 * n <= pages_per_huge_page) {
> +		base = 0;
> +		l = n;
> +		for (i = pages_per_huge_page - 1; i >= 2 * n; i--) {
> +			cond_resched();
> +			clear_user_highpage(page + i, addr + i * PAGE_SIZE);
> +		}

I really like the idea behind the patch but this is not clearing from last
to first byte of the huge page.

What seems to be happening here is clearing from the last page to the
first page and I would think that within each page the clearing is from
first byte to last byte. Maybe more gains can be had by really clearing
from last to first byte of the huge page instead of this jumping over 4k
addresses?