[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210607204942.buratcsapp5fk627@box.shutemov.name>
Date: Mon, 7 Jun 2021 23:49:42 +0300
From: "Kirill A. Shutemov" <kirill@...temov.name>
To: Jann Horn <jannh@...gle.com>
Cc: Matthew Wilcox <willy@...radead.org>,
Linux-MM <linux-mm@...ck.org>, Zi Yan <ziy@...dia.com>,
Peter Xu <peterx@...hat.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
Andrew Morton <akpm@...ux-foundation.org>,
chinwen.chang@...iatek.com,
kernel list <linux-kernel@...r.kernel.org>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
Vlastimil Babka <vbabka@...e.cz>,
Michel Lespinasse <walken@...gle.com>,
syzbot <syzbot+1f52b3a18d5633fa7f82@...kaller.appspotmail.com>
Subject: Re: split_huge_page_to_list() races with page_mapcount() on
migration entry in smaps code? [was: Re: [syzbot] kernel BUG in
__page_mapcount]
On Mon, Jun 07, 2021 at 07:27:23PM +0200, Jann Horn wrote:
> 2. let smaps assume that the mapcount is 1 for all migration entries?
I believe that what we effectively do for migration entries to
non-compound pages:
for (i = 0; i < nr; i++, page++) {
int mapcount = page_mapcount(page);
unsigned long pss = PAGE_SIZE << PSS_SHIFT;
if (mapcount >= 2)
pss /= mapcount;
smaps_page_accumulate(mss, page, PAGE_SIZE, pss, dirty, locked,
mapcount < 2);
}
For non-compound pages with page_count(page) != 1 (== 1 handled
separately) we would have nr == 1 and will look into mapcount, which for
pages under migration is 0. The code above will handle mapcount == 0 as
mapcount == 1. I think it would not be a stretch to do the same for
compound pages here.
I guess we should take an additional argument to smaps_account() which would
indicate that we deal with migration entry and handle it as mapcount == 1.
Hm. Do we need the same for device-private entries?
--
Kirill A. Shutemov
Powered by blists - more mailing lists