All of lore.kernel.org
 help / color / mirror / Atom feed
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: zhong jiang <zhongjiang@huawei.com>
Cc: Minchan Kim <minchan@kernel.org>,
	Michal Hocko <mhocko@kernel.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Qestion] Hit a WARN_ON_ONCE in try_to_unmap_one when runing syzkaller
Date: Thu, 14 Mar 2019 06:27:55 +0000	[thread overview]
Message-ID: <20190314062757.GA27899@hori.linux.bs1.fc.nec.co.jp> (raw)
In-Reply-To: <5C87D848.7030802@huawei.com>

Hi,

On Wed, Mar 13, 2019 at 12:03:20AM +0800, zhong jiang wrote:
...
> 
> Minchan has changed the conditon check from  BUG_ON  to WARN_ON_ONCE in try_to_unmap_one.
> However,  It is still an abnormal condition when PageSwapBacked is not equal to PageSwapCache.
> 
> But Is there any case it will meet the conditon in the mainline.
> 
> It is assumed that PageSwapBacked(page) is true in the anonymous page,   This is to say,  PageSwapcache
> is false. however,  That is impossible because we will update the pte for hwpoison entry.
> 
> Because page is locked ,  Its page flags should not be changed except for PageSwapBacked

try_to_unmap_one() from hwpoison_user_mappings() could reach the
WARN_ON_ONCE() only if TTU_IGNORE_HWPOISON is set, because PageHWPoison()
is set at the beginning of memory_failure().

Clearing TTU_IGNORE_HWPOISON might happen on the following two paths:

  static bool hwpoison_user_mappings(struct page *p, unsigned long pfn,
                                    int flags, struct page **hpagep)
  {
      ...
  
      if (PageSwapCache(p)) {
              pr_err("Memory failure: %#lx: keeping poisoned page in swap cache\n",
                      pfn);
              ttu |= TTU_IGNORE_HWPOISON;
      }
      ...

      mapping = page_mapping(hpage);                                                                           
      if (!(flags & MF_MUST_KILL) && !PageDirty(hpage) && mapping &&                                           
          mapping_cap_writeback_dirty(mapping)) {                                                              
              if (page_mkclean(hpage)) {                                                                       
                      SetPageDirty(hpage);                                                                     
              } else {                                                                                         
                      kill = 0;                                                                                
                      ttu |= TTU_IGNORE_HWPOISON;                                                              
                      pr_info("Memory failure: %#lx: corrupted page was clean: dropped without side effects\n",
                              pfn);                                                                            
              }                                                                                                
      }                                                                                                        
      ...

      unmap_success = try_to_unmap(hpage, ttu);
      ...

So either of the above "ttu |= TTU_IGNORE_HWPOISON" should be executed.
I'm not sure which one, but both paths show printk messages, so if you
could have kernel message log, that might help ...

Thanks,
Naoya Horiguchi

WARNING: multiple messages have this Message-ID (diff)
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: zhong jiang <zhongjiang@huawei.com>
Cc: Minchan Kim <minchan@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Michal Hocko <mhocko@kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Qestion] Hit a WARN_ON_ONCE in try_to_unmap_one when runing syzkaller
Date: Thu, 14 Mar 2019 06:27:55 +0000	[thread overview]
Message-ID: <20190314062757.GA27899@hori.linux.bs1.fc.nec.co.jp> (raw)
In-Reply-To: <5C87D848.7030802@huawei.com>

Hi,

On Wed, Mar 13, 2019 at 12:03:20AM +0800, zhong jiang wrote:
...
> 
> Minchan has changed the conditon check from  BUG_ON  to WARN_ON_ONCE in try_to_unmap_one.
> However,  It is still an abnormal condition when PageSwapBacked is not equal to PageSwapCache.
> 
> But Is there any case it will meet the conditon in the mainline.
> 
> It is assumed that PageSwapBacked(page) is true in the anonymous page,   This is to say,  PageSwapcache
> is false. however,  That is impossible because we will update the pte for hwpoison entry.
> 
> Because page is locked ,  Its page flags should not be changed except for PageSwapBacked

try_to_unmap_one() from hwpoison_user_mappings() could reach the
WARN_ON_ONCE() only if TTU_IGNORE_HWPOISON is set, because PageHWPoison()
is set at the beginning of memory_failure().

Clearing TTU_IGNORE_HWPOISON might happen on the following two paths:

  static bool hwpoison_user_mappings(struct page *p, unsigned long pfn,
                                    int flags, struct page **hpagep)
  {
      ...
  
      if (PageSwapCache(p)) {
              pr_err("Memory failure: %#lx: keeping poisoned page in swap cache\n",
                      pfn);
              ttu |= TTU_IGNORE_HWPOISON;
      }
      ...

      mapping = page_mapping(hpage);                                                                           
      if (!(flags & MF_MUST_KILL) && !PageDirty(hpage) && mapping &&                                           
          mapping_cap_writeback_dirty(mapping)) {                                                              
              if (page_mkclean(hpage)) {                                                                       
                      SetPageDirty(hpage);                                                                     
              } else {                                                                                         
                      kill = 0;                                                                                
                      ttu |= TTU_IGNORE_HWPOISON;                                                              
                      pr_info("Memory failure: %#lx: corrupted page was clean: dropped without side effects\n",
                              pfn);                                                                            
              }                                                                                                
      }                                                                                                        
      ...

      unmap_success = try_to_unmap(hpage, ttu);
      ...

So either of the above "ttu |= TTU_IGNORE_HWPOISON" should be executed.
I'm not sure which one, but both paths show printk messages, so if you
could have kernel message log, that might help ...

Thanks,
Naoya Horiguchi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-03-14  6:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-12 16:03 [Qestion] Hit a WARN_ON_ONCE in try_to_unmap_one when runing syzkaller zhong jiang
2019-03-12 16:03 ` zhong jiang
2019-03-14  6:27 ` Naoya Horiguchi [this message]
2019-03-14  6:27   ` Naoya Horiguchi
2019-03-14  6:27   ` Naoya Horiguchi
2019-03-14  7:54   ` zhong jiang
2019-03-14  7:54     ` zhong jiang
2019-03-14  7:54     ` zhong jiang

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=20190314062757.GA27899@hori.linux.bs1.fc.nec.co.jp \
    --to=n-horiguchi@ah.jp.nec.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=zhongjiang@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.