[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+55aFwcKfyuyMNV37c_JT00039P_VgmOXU_u3gm_RnUR=LGdQ@mail.gmail.com>
Date: Sun, 4 May 2014 14:19:08 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Richard Weinberger <richard@....at>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-mm <linux-mm@...ck.org>, Dave Jones <davej@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Johannes Weiner <hannes@...xchg.org>,
Sasha Levin <sasha.levin@...cle.com>,
Hugh Dickins <hughd@...gle.com>,
Toralf Förster <toralf.foerster@....de>
Subject: Re: [PATCH] mm: Fix force_flush behavior in zap_pte_range()
On Sun, May 4, 2014 at 1:42 PM, Richard Weinberger <richard@....at> wrote:
>
> I cannot tell why UML has it's own tlb gather logic, I suspect nobody
> cared so far to clean up the code.
> That said, I've converted it today to the generic gather logic and it works.
> Sadly I'm still facing the same issues (sigh!).
Ok, so it's not the gathering.
I'm guessing it's because the tlb flush patterns change (we now flush
partial areas for shared mappings with dirty pages - it used to be
that you'd only ever see full ranges before), and that shows some
issue with the whole "fix_range()" thing. So then the kill(9) results
in stopping the page table zapping in the middle, and then you end up
with that "Bad rss-counter" for the file mapping.
Can you try to debug it to see where that "ret" gets set in
fix_range_common() (well, likely deeper, I presume it comes from
update_pte_range() or whatever), to see exactly _what_ it is that
starts failing?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists