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, 21 Aug 2013 09:53:32 -0400
From:	konrad wilk <konrad.wilk@...cle.com>
To:	David Vrabel <david.vrabel@...rix.com>
CC:	Cyrill Gorcunov <gorcunov@...il.com>,
	Andy Lutomirski <luto@...capital.net>,
	Pavel Emelyanov <xemul@...allels.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
	Xen-devel@...ts.xen.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Jan Beulich <jbeulich@...e.com>
Subject: Re: Regression: x86/mm: new _PTE_SWP_SOFT_DIRTY bit conflicts with
 existing use


On 8/21/2013 9:48 AM, David Vrabel wrote:
> All,
>
> 179ef71c (mm: save soft-dirty bits on swapped pages) introduces a new
> PTE bit on x86 _PTE_SWP_SOFT_DIRTY which has the same value as _PTE_PSE
> and _PTE_PAT.
>
> With a Xen PV guest, the use of the _PTE_PAT will result in the page
> having unexpected cachability which will introduce a range of subtle
> performance and correctness issues.  Xen programs the entry 4 in the PAT
> table with WC so a page that was previously WB will end up as WC.
Especially with filesystems which would end up using those pages (as the 
memory allocator
would recycle them) and with corruption in the filesystem. Took months 
to figure
that out.

>
> The use of this bit also appears to preclude the use of (transparent)
> huge pages by the application.  It is not clear if there is something
> else guaranteeing that that there will be no huge pages.
>
> To fix this regression I suggest one or more of:
>
> 1. If no other changes are made, at a mimimum, MEM_SOFT_DIRTY must
> require !XEN and possibly !TRANSPARENT_HUGEPAGE and !HUGETLBFS.  This
> would prevent this option being enabled on the majority of standard
> Linux distributions.
>
> 2. Find a different PTE bit to (re)use.
>
> 3. Avoid clearing the soft dirty bit when repopulating a swapped out page.
>
> 4. Redesign the soft dirty tracking to not require the use of
> architecture specific PTE bits.  e.g., by using a shadow set of
> structures for the soft dirty bit tracking.

Or revert this patch and in 3.12 fix it using one of the options above 
or other ones.
>
> David

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ