linux-kernel - Re: [PATCH] mm: fix negative commitlimit when gigantic hugepages are allocated

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: <20110603120751.GA24840@sgi.com>
Date:	Fri, 3 Jun 2011 07:07:52 -0500
From:	Russ Anderson <rja@....com>
To:	Rafael Aquini <aquini@...ux.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	linux-mm <linux-mm@...ck.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Christoph Lameter <cl@...ux.com>, rja@...ricas.sgi.com
Subject: Re: [PATCH] mm: fix negative commitlimit when gigantic hugepages are allocated

Acked-by: Russ Anderson <rja@....com>

On Thu, Jun 02, 2011 at 11:55:57PM -0300, Rafael Aquini wrote:
> When 1GB hugepages are allocated on a system, free(1) reports
> less available memory than what really is installed in the box.
> Also, if the total size of hugepages allocated on a system is
> over half of the total memory size, CommitLimit becomes
> a negative number.
> 
> The problem is that gigantic hugepages (order > MAX_ORDER)
> can only be allocated at boot with bootmem, thus its frames
> are not accounted to 'totalram_pages'. However,  they are
> accounted to hugetlb_total_pages()
> 
> What happens to turn CommitLimit into a negative number
> is this calculation, in fs/proc/meminfo.c:
> 
>         allowed = ((totalram_pages - hugetlb_total_pages())
>                 * sysctl_overcommit_ratio / 100) + total_swap_pages;
> 
> A similar calculation occurs in __vm_enough_memory() in mm/mmap.c.
> 
> Also, every vm statistic which depends on 'totalram_pages' will render
> confusing values, as if system were 'missing' some part of its memory.
> 
> Reported-by: Russ Anderson <rja@....com>
> Signed-off-by: Rafael Aquini <aquini@...ux.com>
> ---
>  mm/hugetlb.c |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index f33bb31..c67dd0f 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1111,6 +1111,14 @@ static void __init gather_bootmem_prealloc(void)
>  		WARN_ON(page_count(page) != 1);
>  		prep_compound_huge_page(page, h->order);
>  		prep_new_huge_page(h, page, page_to_nid(page));
> +
> +		/* if we had gigantic hugepages allocated at boot time,
> +		 * we need to reinstate the 'stolen' pages to totalram_pages,
> +		 * in order to fix confusing memory reports from free(1)
> +		 * and another side-effects, like CommitLimit going negative.
> +		 */
> +		if (h->order > (MAX_ORDER - 1))
> +			totalram_pages += 1 << h->order;
>  	}
>  }
>  
> -- 
> 1.7.4.4

-- 
Russ Anderson, OS RAS/Partitioning Project Lead  
SGI - Silicon Graphics Inc          rja@....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/