On Sat, May 3, 2014 at 4:37 PM, Richard Weinberger <richard@xxxxxx> wrote:
> Commit 1cf35d47 (mm: split 'tlb_flush_mmu()' into tlb flushing and memory freeing parts)
> accidently changed the behavior of the force_flush variable.
No it didn't. There was nothing accidental about it, and it doesn't
even change it the way you claim.
> Before the patch it was set by __tlb_remove_page(). Now it is only set to 1
> if __tlb_remove_page() returns false but never set back to 0 if __tlb_remove_page()
> returns true.
It starts out as zero. If __tlb_remove_page() returns true, it never
gets set to anything *but* zero, except by the dirty shared mapping
case that *needs* to set it to non-zero, exactly because it *needs* to
flush the TLB before releasing the pte lock.
Which was the whole point of the patch.
Your explanation makes no sense for _another_ reason: even with your
patch, it never gets set back to zero, since if it gets set to one you
have that "break" in there. So the whole "gets set back to zero" is
simply not relevant or true, with or with the patch.
The only place it actually gets zeroed (apart from initialization) is
for the "goto again" case, which does it (and always did it)
> Fixes BUG: Bad rss-counter state ...
> and
> kernel BUG at mm/filemap.c:202!
So tell us more about those actual problems, because your patch and
explanation is clearly wrong.
What hardware, what load, what "kernel BUG at filemap.c:202"?
The shared dirty fix may certainly be exposing some other issue, but
the only report I have seen about filemap.c:202 was reported by Dave
Jones ten *days* before the commit you talk about was even done.
So this whole thing makes no sense what-so-ever.
Linus
--
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>