linux-kernel - Re: [PATCH] mm: Save soft-dirty bits on swapped pages

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:	Wed, 24 Jul 2013 10:06:53 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	Linux MM <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Matt Mackall <mpm@...enic.com>,
	Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [PATCH] mm: Save soft-dirty bits on swapped pages

On Wed, Jul 24, 2013 at 9:37 AM, Cyrill Gorcunov <gorcunov@...il.com> wrote:
> On Wed, Jul 24, 2013 at 09:23:14AM -0700, Andy Lutomirski wrote:
>> On Wed, Jul 24, 2013 at 9:08 AM, Cyrill Gorcunov <gorcunov@...il.com> wrote:
>> > Andy Lutomirski reported that in case if a page with _PAGE_SOFT_DIRTY
>> > bit set get swapped out, the bit is getting lost and no longer
>> > available when pte read back.
>>
>> Potentially silly question (due to my completely lack of understanding
>> of how swapping works in Linux): what about file-backed pages?
>> (Arguably these would be best supported by filesystems instead of by
>> the core vm, in which case it might make sense to drop soft-dirty
>> support for these pages entirely.)
>
> Hi Andy, if I understand you correctly "file-backed pages" are carried
> in pte with _PAGE_FILE bit set and the swap soft-dirty bit won't be
> used on them but _PAGE_SOFT_DIRTY will be set on write if only I've
> not missed something obvious (Pavel?).

If I understand this stuff correctly, the vmscan code calls
try_to_unmap when it reclaims memory, which makes its way into
try_to_unmap_one, which clears the pte (and loses the soft-dirty bit).

--Andy
--
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/