linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, Michal Hocko <mhocko@suse.cz>,
	linux-mm@kvack.org
Subject: Re: [PATCH] mm/swapfile: fix swapoff vs. software dirty bits
Date: Thu, 17 Sep 2015 22:31:52 +0300	[thread overview]
Message-ID: <20150917193152.GJ2000@uranus> (raw)
In-Reply-To: <1442480339-26308-2-git-send-email-schwidefsky@de.ibm.com>

On Thu, Sep 17, 2015 at 10:58:59AM +0200, Martin Schwidefsky wrote:
> Fixes a regression introduced with commit 179ef71cbc085252
> "mm: save soft-dirty bits on swapped pages"
> 
> The maybe_same_pte() function is used to match a swap pte independent
> of the swap software dirty bit set with pte_swp_mksoft_dirty().
> 
> For CONFIG_HAVE_ARCH_SOFT_DIRTY=y but CONFIG_MEM_SOFT_DIRTY=n the
> software dirty bit may be set but maybe_same_pte() will not recognize
> a software dirty swap pte. Due to this a 'swapoff -a' will hang.
> 
> The straightforward solution is to replace CONFIG_MEM_SOFT_DIRTY
> with HAVE_ARCH_SOFT_DIRTY in maybe_same_pte().
> 
> Cc: linux-mm@kvack.org
> Cc: Cyrill Gorcunov <gorcunov@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@suse.cz>
> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
> ---
>  mm/swapfile.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 5887731..bf7da58 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -1113,7 +1113,7 @@ unsigned int count_swap_pages(int type, int free)
>  
>  static inline int maybe_same_pte(pte_t pte, pte_t swp_pte)
>  {
> -#ifdef CONFIG_MEM_SOFT_DIRTY
> +#ifdef CONFIG_HAVE_ARCH_SOFT_DIRTY
>  	/*
>  	 * When pte keeps soft dirty bit the pte generated
>  	 * from swap entry does not has it, still it's same

You know, I seem to miss how this might help. If CONFIG_MEM_SOFT_DIRTY=n
then all related helpers are nop'ed.

In particular in the commit you mentioned

+static inline int maybe_same_pte(pte_t pte, pte_t swp_pte)
+{
+#ifdef CONFIG_MEM_SOFT_DIRTY
+       /*
+        * When pte keeps soft dirty bit the pte generated
+        * from swap entry does not has it, still it's same
+        * pte from logical point of view.
+        */
+       pte_t swp_pte_dirty = pte_swp_mksoft_dirty(swp_pte);
+       return pte_same(pte, swp_pte) || pte_same(pte, swp_pte_dirty);
+#else
+       return pte_same(pte, swp_pte);
+#endif
+}
+
...
@@ -892,7 +907,7 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t *pmd,
        }
 
        pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
-       if (unlikely(!pte_same(*pte, swp_entry_to_pte(entry)))) {
+       if (unlikely(!maybe_same_pte(*pte, swp_entry_to_pte(entry)))) {
                mem_cgroup_cancel_charge_swapin(memcg);
                ret = 0;
                goto out;
@@ -947,7 +962,7 @@ static int unuse_pte_range(struct vm_area_struct *vma, pmd_t *pmd,
                 * swapoff spends a _lot_ of time in this loop!
                 * Test inline before going to call unuse_pte.
                 */
-               if (unlikely(pte_same(*pte, swp_pte))) {
+               if (unlikely(maybe_same_pte(*pte, swp_pte))) {
                        pte_unmap(pte);
                        ret = unuse_pte(vma, pmd, addr, entry, page);
                        if (ret)

Thus when CONFIG_MEM_SOFT_DIRTY = n, the unuse_pte will be the same
as it were without the patch, calling pte_same.

Now to the bit itself

#ifdef CONFIG_MEM_SOFT_DIRTY
#define _PAGE_SWP_SOFT_DIRTY_PAGE_PSE
#else
#define _PAGE_SWP_SOFT_DIRTY_PAGE_PSE(_AT(pteval_t, 0))
#endif

it's 0 if CONFIG_MEM_SOFT_DIRTY=n, so any setup of this
bit will simply become nop

#ifdef CONFIG_HAVE_ARCH_SOFT_DIRTY
static inline pte_t pte_swp_mksoft_dirty(pte_t pte)
{
	return pte_set_flags(pte, _PAGE_SWP_SOFT_DIRTY);
}

static inline int pte_swp_soft_dirty(pte_t pte)
{
	return pte_flags(pte) & _PAGE_SWP_SOFT_DIRTY;
}

static inline pte_t pte_swp_clear_soft_dirty(pte_t pte)
{
	return pte_clear_flags(pte, _PAGE_SWP_SOFT_DIRTY);
}
#endif

So I fear I'm lost where this "set" of the bit comes from
when CONFIG_MEM_SOFT_DIRTY=n.

Martin, could you please elaborate? Seems I'm missing
something obvious.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2015-09-17 19:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-17  8:58 [PATCH] hanging swapoff with HAVE_ARCH_SOFT_DIRTY=y Martin Schwidefsky
2015-09-17  8:58 ` [PATCH] mm/swapfile: fix swapoff vs. software dirty bits Martin Schwidefsky
2015-09-17  9:53   ` Cyrill Gorcunov
2015-09-17 19:31   ` Cyrill Gorcunov [this message]
2015-09-18  6:58     ` Martin Schwidefsky
2015-09-18  7:15       ` Cyrill Gorcunov
2015-09-18  8:20         ` Martin Schwidefsky
2015-09-18  8:53           ` Cyrill Gorcunov
2015-09-18  9:10             ` Martin Schwidefsky
2015-09-18  9:28               ` Cyrill Gorcunov
2015-09-18 10:11                 ` Martin Schwidefsky
2015-09-18 20:21               ` Cyrill Gorcunov
2015-09-21  7:10                 ` Martin Schwidefsky
2015-09-21  7:30                   ` Cyrill Gorcunov
2015-09-21  7:40                     ` Martin Schwidefsky
2015-09-21  7:54                       ` Cyrill Gorcunov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150917193152.GJ2000@uranus \
    --to=gorcunov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=mingo@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).