linux-kernel - Re: [kvm-devel] [PATCH] export notifier #1

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: <20080124154239.GP7141@v2.random>
Date:	Thu, 24 Jan 2008 16:42:39 +0100
From:	Andrea Arcangeli <andrea@...ranet.com>
To:	Christoph Lameter <clameter@....com>
Cc:	Robin Holt <holt@....com>, Avi Kivity <avi@...ranet.com>,
	Izik Eidus <izike@...ranet.com>, Andrew Morton <akpm@...l.org>,
	Nick Piggin <npiggin@...e.de>, kvm-devel@...ts.sourceforge.net,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	steiner@....com, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	daniel.blueman@...drics.com, Hugh Dickins <hugh@...itas.com>
Subject: Re: [kvm-devel] [PATCH] export notifier #1

On Wed, Jan 23, 2008 at 12:27:47PM -0800, Christoph Lameter wrote:
> There are still dirty bit issues.

Yes, but no big issues given ->invalidate_page is fully capable of
running set_page_dirty if needed.

> > The window that you must close with that bitflag is the request coming
> > from the remote node to map the page after the linux pte has been
> > cleared. If you map the page in a remote node after the linux pte has
> > been cleared ->invalidate_page won't be called again because the page
> > will look unmapped in the linux VM. Now invalidate_page will clear the
> > bitflag, so the map requests will block. But where exactly you know
> > that the linux pte has been cleared so you can "unblock" the map
> > requests? If a page is not mapped by some linux pte, mm/rmap.c will
> > never be called and this is why any notification in mm/rmap.c should
> > track the "address space" and not the "physical page".
> 
> The subsystem needs to establish proper locking for that case.

How? I Your answer was to have the subsystem-fault wait PG_exported to
return ON... when later you told me the subsystem-fault is the thing
supposed to set PG_exported ON again... Perhaps you really could
invent a proper locking to make your #v1 workable somehow but I didn't
see a sign of it yet.

Infact I'm not so sure if all will be race-free with
invalidate_page_after (given you pretend to call it outside the PT
lock so concurrent linux minor faults can happen in parallel of your
invalidate_page_after) but at least it has a better chance to work
without having to invent much new complex locking.

> It also deals f.e. with page dirty status.

I think you should consider if you can also build a rmap per-MM like
KVM does and index it by the virtual address like KVM does.
--
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/