linux-kernel - Re: [PATCH 0/9] Hugepage migration (v2)

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]

Message-ID: <alpine.DEB.2.00.1008110806070.673@router.home>
Date:	Wed, 11 Aug 2010 08:09:59 -0500 (CDT)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Naoya Horiguchi <n-horiguchi@...jp.nec.com>
cc:	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mel@....ul.ie>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Jun'ichi Nomura <j-nomura@...jp.nec.com>,
	linux-mm <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/9] Hugepage migration (v2)

On Tue, 10 Aug 2010, Naoya Horiguchi wrote:

> There were two points of issue.
>
> * Dividing hugepage migration functions from original migration code.
>   This is to avoid complexity.
>   In present version, some high level migration routines are defined to handle
>   hugepage, but some low level routines (such as migrate_copy_page() etc.)
>   are shared with original migration code in order not to increase duplication.

I hoped that we can avoid the branching for taking stuff off the lru and
put pages back later to the lru. Seems that we still do that. Can be
refactor the code in such a way that the lru handling cleanly isolates?
There are now multiple use cases for migration that could avoid LRU
handling even for PAGE_SIZE pages.

> * Locking problem between direct I/O and hugepage migration
>   As a result of digging the race between hugepage I/O and hugepage migration,
>   (where hugepage I/O can be seen only in direct I/O,)
>   I noticed that without additional locking we can avoid this race condition
>   because in direct I/O we can get whether some subpages are under I/O or not
>   from reference count of the head page and hugepage migration safely fails
>   if some references remain.  So no data lost should occurs on the migration
>   concurrent with direct I/O.

Can you also avoid refcounts being increased during migration? The page
lock is taken for the PAGE_SIZEd migration case. Can direct I/O be stopped
by taking the page lock on the head page? If not then races can still
occur.

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