On Tue, 23 May 2017, Xishi Qiu wrote: > On 2017/5/23 3:26, Hugh Dickins wrote: > > I mean, there are various places in mm/memory.c which decide what they > > intend to do based on orig_pte, then take pte lock, then check that > > pte_same(pte, orig_pte) before taking it any further. If a pte_same() > > check were missing (I do not know of any such case), then two racing > > tasks might install the same pte, one on top of the other - page > > mapcount being incremented twice, but decremented only once when > > that pte is finally unmapped later. > > > > Hi Hugh, > > Do you mean that the ptes from two racing point to the same page? > or the two racing point to two pages, but one covers the other later? > and the first page maybe alone in the lru list, and it will never be freed > when the process exit. > > We got this info before crash. > [26068.316592] BUG: Bad rss-counter state mm:ffff8800a7de2d80 idx:1 val:1 I might mean either: you are taking my suggestion too seriously, it is merely a suggestion of one way in which this could happen. Another way is ordinary memory corruption (whether by software error or by flipped DRAM bits) of a page table: that could end up here too. Hugh -- 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>
