linux-kernel - Re: [PATCH linux-next] Fix shmem huge page failed to set F_SEAL

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: <1f486393-3829-4618-39a1-931afc580835@oracle.com>
Date:   Wed, 16 Feb 2022 17:00:46 -0800
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     cgel.zte@...il.com, hughd@...gle.com, kirill@...temov.name,
        songliubraving@...com, akpm@...ux-foundation.org
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        yang.yang29@....com.cn, wang.yong12@....com.cn,
        Zeal Robot <zealci@....com.cn>
Subject: Re: [PATCH linux-next] Fix shmem huge page failed to set F_SEAL_WRITE
 attribute problem

On 2/14/22 23:37, cgel.zte@...il.com wrote:
> From: wangyong <wang.yong12@....com.cn>
> 
> After enabling tmpfs filesystem to support transparent hugepage with the
> following command:
>  echo always > /sys/kernel/mm/transparent_hugepage/shmem_enabled
> The docker program adds F_SEAL_WRITE through the following command will
> prompt EBUSY.
>  fcntl(5, F_ADD_SEALS, F_SEAL_WRITE)=-1.
> 
> It is found that in memfd_wait_for_pins function, the page_count of
> hugepage is 512 and page_mapcount is 0, which does not meet the
> conditions:
>  page_count(page) - page_mapcount(page) != 1.
> But the page is not busy at this time, therefore, the page_order of
> hugepage should be taken into account in the calculation.
> 
> Reported-by: Zeal Robot <zealci@....com.cn>
> Signed-off-by: wangyong <wang.yong12@....com.cn>
> ---
>  mm/memfd.c | 16 +++++++++++++---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/memfd.c b/mm/memfd.c
> index 9f80f162791a..26d1d390a22a 100644
> --- a/mm/memfd.c
> +++ b/mm/memfd.c
> @@ -31,6 +31,7 @@
>  static void memfd_tag_pins(struct xa_state *xas)
>  {
>  	struct page *page;
> +	int count = 0;
>  	unsigned int tagged = 0;
>  
>  	lru_add_drain();
> @@ -39,8 +40,12 @@ static void memfd_tag_pins(struct xa_state *xas)
>  	xas_for_each(xas, page, ULONG_MAX) {
>  		if (xa_is_value(page))
>  			continue;
> +
>  		page = find_subpage(page, xas->xa_index);
> -		if (page_count(page) - page_mapcount(page) > 1)
> +		count = page_count(page);
> +		if (PageTransCompound(page))

PageTransCompound() is true for hugetlb pages as well as THP.  And, hugetlb
pages will not have a ref per subpage as THP does.  So, I believe this will
break hugetlb seal usage.

I was trying to do some testing via the memfd selftests, but those have some
other issues for hugetlb that need to be fixed. :(
-- 
Mike Kravetz

> +			count -= (1 << compound_order(compound_head(page))) - 1;
> +		if (count - page_mapcount(page) > 1)
>  			xas_set_mark(xas, MEMFD_TAG_PINNED);
>  
>  		if (++tagged % XA_CHECK_SCHED)
> @@ -67,11 +72,12 @@ static int memfd_wait_for_pins(struct address_space *mapping)
>  {
>  	XA_STATE(xas, &mapping->i_pages, 0);
>  	struct page *page;
> -	int error, scan;
> +	int error, scan, count;
>  
>  	memfd_tag_pins(&xas);
>  
>  	error = 0;
> +	count = 0;
>  	for (scan = 0; scan <= LAST_SCAN; scan++) {
>  		unsigned int tagged = 0;
>  
> @@ -89,8 +95,12 @@ static int memfd_wait_for_pins(struct address_space *mapping)
>  			bool clear = true;
>  			if (xa_is_value(page))
>  				continue;
> +
>  			page = find_subpage(page, xas.xa_index);
> -			if (page_count(page) - page_mapcount(page) != 1) {
> +			count = page_count(page);
> +			if (PageTransCompound(page))
> +				count -= (1 << compound_order(compound_head(page))) - 1;
> +			if (count - page_mapcount(page) != 1) {
>  				/*
>  				 * On the last scan, we clean up all those tags
>  				 * we inserted; but make a note that we still