linux-kernel - Re: [PATCH 1/3] mm/swap.c: introduce put_[un]refcounted_compound_page helpers for spliting put_compound

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: <20140430205011.GA27455@node.dhcp.inet.fi>
Date:	Wed, 30 Apr 2014 23:50:11 +0300
From:	"Kirill A. Shutemov" <kirill@...temov.name>
To:	Jianyu Zhan <nasa4836@...il.com>
Cc:	akpm@...ux-foundation.org, hannes@...xchg.org, riel@...hat.com,
	aarcange@...hat.com, mgorman@...e.de, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] mm/swap.c: introduce
 put_[un]refcounted_compound_page helpers for spliting put_compound_page

On Tue, Apr 29, 2014 at 05:42:07PM +0800, Jianyu Zhan wrote:
> Currently, put_compound_page should carefully handle tricky case
> to avoid racing with compound page releasing or spliting, which
> makes it growing quite lenthy(about 200+ lines) and need deep
> tab indention, which makes it quite hard to follow and maintain.
> 
> This patch(and the next patch) tries to refactor this function.
> It is a prepared patch.
> 
> Based on the code skeleton of put_compound_page:
> 
> put_compound_pge:

Typo.

>         if !PageTail(page)
>         	put head page fastpath;
> 		return;
> 
>         /* else PageTail */
>         page_head = compound_head(page)
>         if !__compound_tail_refcounted(page_head)
> 		put head page optimal path; <---(1)
> 		return;
>         else
> 		put head page slowpath; <--- (2)
>                 return;
> 
> This patch introduces two helpers, put_[un]refcounted_compound_page,
> handling the code path (1) and code path (2), respectively. They both
> are tagged __always_inline, thus it elmiates function call overhead,
> making them operating the same way as before.
> 
> They are almost copied verbatim(except one place, a "goto out_put_single"
> is expanded), with some comments rephrasing.
> 
> Signed-off-by: Jianyu Zhan <nasa4836@...il.com>
> ---
>  mm/swap.c | 142 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 142 insertions(+)
> 
> diff --git a/mm/swap.c b/mm/swap.c
> index c0cd7d0..a576449 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -79,6 +79,148 @@ static void __put_compound_page(struct page *page)
>  	(*dtor)(page);
>  }
>  
> +/**
> + * Two special cases here: we could avoid taking compound_lock_irqsave
> + * and could skip the tail refcounting(in _mapcount).
> + *
> + * 1. Hugetlbfs page:
> + *
> + *    PageHeadHuge will remain true until the compound page
> + *    is released and enters the buddy allocator, and it could
> + *    not be split by __split_huge_page_refcount().
> + *
> + *    So if we see PageHeadHuge set, and we have the tail page pin,
> + *    then we could safely put head page.
> + *
> + * 2. Slab THP page:

There's no such thing. It called Slab compound page.

> + *
> + *    PG_slab is cleared before the slab frees the head page, and
> + *    tail pin cannot be the last reference left on the head page,
> + *    because the slab code is free to reuse the compound page
> + *    after a kfree/kmem_cache_free without having to check if
> + *    there's any tail pin left.  In turn all tail pinsmust be always
> + *    released while the head is still pinned by the slab code
> + *    and so we know PG_slab will be still set too.
> + *
> + *    So if we see PageSlab set, and we have the tail page pin,
> + *    then we could safely put head page.
> + */
-- 
 Kirill A. Shutemov
--
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/