Re: mm: kernel BUG at mm/mlock.c:82!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/18/2013 03:02 AM, Wanpeng Li wrote:
Hi Motohiro,
On Tue, Dec 17, 2013 at 08:32:49AM -0800, Motohiro Kosaki wrote:


-----Original Message-----
From: owner-linux-mm@xxxxxxxxx [mailto:owner-linux-mm@xxxxxxxxx] On
Behalf Of Wanpeng Li
Sent: Tuesday, December 17, 2013 3:27 AM
To: Sasha Levin
Cc: Bob Liu; Andrew Morton; linux-mm@xxxxxxxxx; Michel Lespinasse;
npiggin@xxxxxxx; Motohiro Kosaki JP; riel@xxxxxxxxxx
Subject: Re: mm: kernel BUG at mm/mlock.c:82!

Hi Sasha,
On Tue, Dec 17, 2013 at 01:46:54AM -0500, Sasha Levin wrote:
On 12/17/2013 12:39 AM, Bob Liu wrote:
cc'd more people.

On 12/17/2013 09:04 AM, Sasha Levin wrote:
Hi all,

While fuzzing with trinity inside a KVM tools guest running latest
-next kernel, I've stumbled on the following spew.

Codewise, it's pretty straightforward. In try_to_unmap_cluster():

                 page = vm_normal_page(vma, address, *pte);
                 BUG_ON(!page || PageAnon(page));

                 if (locked_vma) {
                         mlock_vma_page(page);   /* no-op if already
mlocked */
                         if (page == check_page)
                                 ret = SWAP_MLOCK;
                         continue;       /* don't unmap */
                 }

And the BUG triggers once we see that 'page' isn't locked.


Yes, I didn't see any place locked the corresponding page in
try_to_unmap_cluster().

I'm afraid adding lock_page() over there may cause potential deadlock.
How about just remove the BUG_ON() in mlock_vma_page()?

Welp, it's been there for 5 years now - there should be a good reason to
justify removing it.


Page should be locked before invoke try_to_unmap(), this check can't be
removed since this bug is just triggered by confirm !check page hold page
lock in virtual scan during nolinear VMAs pages aging. Avoid to confirm !check
page hold page lock is acceptable.

That's a try_to_unmap()'s assumption and it already have  BUG_ON(!PageLocked(page)).
We can remove wrong BUG_ON from mlock_vma_page() simply. Mlock_vma_page() doesn't depend on page-locked.


There is a race between mlock_vma_page() and munlock_vma_page(). Both of
them should hold page lock and have a BUG_ON assumption.

I think the atomic operations on PageMlocked prevent such races. Also these functions seem to be always called with mmap_sem held.

Regards,
Wanpeng Li



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


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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]