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-next>] [day] [month] [year] [list]
Date:	Thu, 03 Apr 2008 17:05:40 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Yasunori Goto <y-goto@...fujitsu.com>,
	Dave Hansen <dave@...ux.vnet.ibm.com>
Cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	Christoph Lameter <clameter@....com>
Subject: [PATCH 0 of 6] [RFC] another attempt at making hotplug memory and xen
	play together

Hi hotplug-memory people,

Here's my current set of WIP patches for using hotplug memory with the
Xen balloon driver.  I'm including all the xen-balloon patches so you
have context for evaluating my hotplug-memory changes.

The gist of the changes to the hotplug memory subsystem is:

- split online_pages up so that users can grow the zones and actually
  online the pages as separate operations,

- remove a bunch of duplicate definitions of online_page() (this is
  just a generally useful cleanup, and it serves to make the later
  change smaller)

- add a section_ops structure, which defines functions to online and
  offline pages.  By default this just calls the standard
  online_page() function, but the xen-balloon driver can install its
  own version which avoids onlining pages with no backing store.

The latter is my generalization of Kamezawa-san's suggestion to put a
hook in the x86-32 online_page() function.  My problem with this idea
is 1) how should the Xen callback know whether it should do anything
special with a given page, and 2) what would happen if two people
wanted to use the hook?  Generally, when we want different kinds of
the same object to have different behaviours, we add an ops structure
and fill it out appropriately, so that's what I decided to do.
Unfortunately threading the ops pointer through the callchain makes
the patch a little large, but not very complex.

Thanks,
	J


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