All of lore.kernel.org
 help / color / mirror / Atom feed
From: zhong jiang <zhongjiang@huawei.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Minchan Kim <minchan@kernel.org>, Hugh Dickins <hughd@google.com>,
	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 15:54:09 +0800	[thread overview]
Message-ID: <5C8A08A1.3090403@huawei.com> (raw)
In-Reply-To: <20190314062757.GA27899@hori.linux.bs1.fc.nec.co.jp>

On 2019/3/14 14:27, Naoya Horiguchi wrote:
> 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 ...
Thank you for your response.

Unfortunately, I lost the printk log. I was looking for it before and support us for further analysis.

It's very weird to get there. Assume that TTU_IGNORE_HWPOSISON is set. There is the two case.

First, PageSwapCache is set and page has been locked. Theoretically WARN_ON_ONCE should not be triggered.
Second, We should assume the page belongs to file page.:-(

I will go on reproducing the issue and get the printk message log.

Thanks
zhong jiang
> Thanks,
> Naoya Horiguchi
>
> .
>



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

WARNING: multiple messages have this Message-ID (diff)
From: zhong jiang <zhongjiang@huawei.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.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>,
	Hugh Dickins <hughd@google.com>
Subject: Re: [Qestion] Hit a WARN_ON_ONCE in try_to_unmap_one when runing syzkaller
Date: Thu, 14 Mar 2019 15:54:09 +0800	[thread overview]
Message-ID: <5C8A08A1.3090403@huawei.com> (raw)
In-Reply-To: <20190314062757.GA27899@hori.linux.bs1.fc.nec.co.jp>

On 2019/3/14 14:27, Naoya Horiguchi wrote:
> 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 ...
Thank you for your response.

Unfortunately, I lost the printk log. I was looking for it before and support us for further analysis.

It's very weird to get there. Assume that TTU_IGNORE_HWPOSISON is set. There is the two case.

First, PageSwapCache is set and page has been locked. Theoretically WARN_ON_ONCE should not be triggered.
Second, We should assume the page belongs to file page.:-(

I will go on reproducing the issue and get the printk message log.

Thanks
zhong jiang
> Thanks,
> Naoya Horiguchi
>
> .
>



  reply	other threads:[~2019-03-14  7:54 UTC|newest]

Thread overview: 5+ 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-14  6:27 ` Naoya Horiguchi
2019-03-14  6:27   ` Naoya Horiguchi
2019-03-14  7:54   ` zhong jiang [this message]
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=5C8A08A1.3090403@huawei.com \
    --to=zhongjiang@huawei.com \
    --cc=hughd@google.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=n-horiguchi@ah.jp.nec.com \
    --cc=vbabka@suse.cz \
    /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.