linux-kernel - Re: [RFC PATCH 1/1] mm: Another attempt to monitor task's memory changes

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 09 Apr 2013 18:52:10 +0400
From:	Pavel Emelyanov <xemul@...allels.com>
To:	KOSAKI Motohiro <kosaki.motohiro@...il.com>
CC:	Linux MM <linux-mm@...ck.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Matt Mackall <mpm@...enic.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Glauber Costa <glommer@...allels.com>,
	Matthew Wilcox <willy@...ux.intel.com>
Subject: Re: [RFC PATCH 1/1] mm: Another attempt to monitor task's memory
 changes

On 04/09/2013 03:10 AM, KOSAKI Motohiro wrote:
>> This approach works on any task via it's proc, and can be used on different
>> tasks in parallel.
>>
>> Also, Andrew was asking for some performance numbers related to the change.
>> Now I can say, that as long as soft dirty bits are not cleared, no performance
>> penalty occur, since the soft dirty bit and the regular dirty bit are set at 
>> the same time within the same instruction. When soft dirty is cleared via 
>> clear_refs, the task in question might slow down, but it will depend on how
>> actively it uses the memory.
>>
>>
>> What do you think, does it make sense to develop this approach further?
> 
> When touching mmaped page, cpu turns on dirty bit but doesn't turn on soft dirty.

Yes. BTW, I've just thought that "soft" in soft dirty should be read as softWARE,
i.e. this bit is managed by kernel, rather than CPU.

> So, I'm not convinced how to use this flag. Please show us your userland algorithm
> how to detect diff.

It's like this:

1. First do "echo 4 > /proc/$pid/clear_refs".
   At that point kernel clears the soft dirty _and_ the writable bits from all ptes
   of process $pid. From now on every write to any page will result in #pf and the
   subsequent call to pte_mkdirty/pmd_mkdirty, which in turn will set the soft dirty
   flag.

2. Then read the /proc/$pid/pagemap (well, /proc/$pid/pagemap2 when it will appear)
   and check the soft-dirty bit reported there (in this RFC patch it's the
   PM_SOFT_DIRTY one). If set, the respective pte was written to since last call
   to clear refs. 

Thanks,
Pavel
--
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/