linux-kernel - RE: [PATCH 1/1] mm: Export a function to read vm_committed

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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1211131255310.5164@chino.kir.corp.google.com>
Date:	Tue, 13 Nov 2012 13:04:57 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
cc:	KY Srinivasan <kys@...rosoft.com>,
	Konrad Wilk <konrad.wilk@...cle.com>,
	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
	devel@...uxdriverproject.org, olaf@...fle.de, apw@...onical.com,
	andi@...stfloor.org, akpm@...ux-foundation.org, linux-mm@...ck.org,
	kamezawa.hiroyuki@...il.com, mhocko@...e.cz, hannes@...xchg.org,
	yinghan@...gle.com
Subject: RE: [PATCH 1/1] mm: Export a function to read vm_committed_as

On Tue, 13 Nov 2012, Dan Magenheimer wrote:

> KY is simply asking that the data item be exported so that he can
> use it from a new module.  No change to the Xen selfballoon driver
> is necessary right now and requiring one only gets in the way of the
> patch.  At some future time, the Xen selfballoon driver can, at its
> leisure, switch to use the new exported function but need not
> unless/until it is capable of being loaded as a module.
> 

That's obvious.

> And, IIUC, you are asking that KY's proposed new function include a
> comment about how it is used by Xen?  How many kernel globals/functions
> document at their point of declaration the intent of all the in-kernel
> users that use/call them?  That seems a bit unreasonable.  There is a
> very long explanatory comment at the beginning of the Xen
> selfballoon driver code already.
> 

Sorry, I don't think it's unreasonable at all: if you're going to be using 
a symbol which was always assumed to be internal to the VM for other 
purposes and then that usage becomes convoluted with additional usage like 
in KY's patch, then no VM hacker will ever know what a change to that 
symbol means outside of the VM.  There's been a lot of confusion about why 
this heuristic is needed outside the VM and whether the symbol is actually 
the correct choice, so verbosity as to the intent of what it is to 
represent is helpful for a maintainable kernel.

Presumably xen is hijacking that symbol for a similar purpose to KY's 
purpose, but perhaps I was too optimistic that others would help to 
solidify the semantics in which it is being used and describe it 
concisely.
--
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/