lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 26 Jan 2015 16:00:20 -0800 (PST) From: David Rientjes <rientjes@...gle.com> To: Primiano Tucci <primiano@...omium.org> cc: "Kirill A. Shutemov" <kirill@...temov.name>, Petr Cermak <petrcermak@...omium.org>, linux-kernel@...r.kernel.org, linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>, Bjorn Helgaas <bhelgaas@...gle.com>, Hugh Dickins <hughd@...gle.com> Subject: Re: [PATCH v2 2/2] task_mmu: Add user-space support for resetting mm->hiwater_rss (peak RSS) On Fri, 23 Jan 2015, Primiano Tucci wrote: > > If you reset the hwm for a process, rss grows to 100MB, another process > > resets the hwm, and you see a hwm of 2MB, that invalidates the hwm > > entirely. > > Not sure I follow this scenario. Where does the 2MB come from? It's a random number that the hwm gets reset to after the other process clears it. > How can > you see a hwm of 2MB, under which conditions? HVM can never be < RSS. > Again, what you are talking about is the case of two profilers racing > for using the same interface (hwm). > This is the same case today of the PG_referenced bit. > PG_referenced bit is not tracking the highest rss a process has ever attained. PG_referenced is understood to be clearable at any time and the only guarantee is that it was at least cleared before returning from the write. It could be set again before the write returns as well, but we can be sure that it was at least cleared. With your approach, which completely invalidates the entire purpose of hwm, the following is possible: process A process B --------- --------- read hwm = 50MB read hwm = 50MB write to clear hwm rss goes to 100MB write to clear hwm rss goes to 2MB read hwm = 2MB read hwm = 2MB This is a result of allowing something external (process B) be able to clear hwm so that you never knew the value went to 100MB. That's the definition of a race, I don't know how to explain it any better and making any connection between clearing PG_referenced and mm->hiwater_rss is a stretch. This approach just makes mm->hiwater_rss meaningless. -- 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