Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
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
Thread-Topic: [Qestion] Hit a WARN_ON_ONCE in try_to_unmap_one when runing
 syzkaller
Thread-Index: AQHU2O0je1X84FRQ5UO03r19PzuDFKYKFWaA
Date:   Thu, 14 Mar 2019 06:27:55 +0000
Message-ID: <20190314062757.GA27899@hori.linux.bs1.fc.nec.co.jp>
References: <5C87D848.7030802@huawei.com>
In-Reply-To: <5C87D848.7030802@huawei.com>
Accept-Language: en-US, ja-JP
Content-Language: ja-JP
Content-Type: text/plain; charset="iso-2022-jp"
Content-ID: <4B7AEFEF8D2342479BEA063B334FC83A@gisp.nec.co.jp>
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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