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

Message-ID: <d85b47d7-00d0-4ebd-afdf-1e69747d0a91@default>
Date:	Tue, 13 Nov 2012 07:41:25 -0800 (PST)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	KY Srinivasan <kys@...rosoft.com>,
	David Rientjes <rientjes@...gle.com>
Cc:	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

> From: KY Srinivasan [mailto:kys@...rosoft.com]
> Subject: RE: [PATCH 1/1] mm: Export a function to read vm_committed_as
> 
> > From: David Rientjes [mailto:rientjes@...gle.com]
> > Sent: Monday, November 12, 2012 6:49 PM
> > To: Dan Magenheimer
> > Cc: KY Srinivasan; Konrad Wilk; 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 Mon, 12 Nov 2012, Dan Magenheimer wrote:
> >
> > > > > Why?  Is xen using it for a different inference?
> > > >
> > > > I think it is good to separate these patches. Dan (copied here) wrote the code
> > for the
> > > > Xen self balloon driver. If it is ok with him I can submit the patch for Xen as
> > well.
> > >
> > > Hi KY --
> > >
> > > If I understand correctly, this would be only a cosmetic (function renaming)
> > change
> > > to the Xen selfballooning code.  If so, then I will be happy to Ack when I
> > > see the patch.  However, Konrad (konrad.wilk@...cle.com) is the maintainer
> > > for all Xen code so you should ask him... and (from previous painful experience)
> > > it can be difficult to sync even very simple interdependent changes going
> > through
> > > different maintainers without breaking linux-next.  So I can't offer any
> > > help with that process, only commiseration. :-(
> > >
> >
> > I think this should be done in the same patch as the function getting
> > introduced with a cc to Konrad and routed through -mm; even better,
> > perhaps he'll have some useful comments for how this is used for xen that
> > can be included for context.
> >
> Ok; I will send out a single patch. I am hoping this can be applied soon as Hyper-V balloon
> driver is queued behind this.
> 
> Regards,
> K. Y

David --

Having caught up on the thread now, I'm a bit confused about your
requirement for KY to patch the Xen selfballooning code.

The data item we are talking about here, committed_as, is defined
by a kernel<->userland ABI, visible to userland via /proc/meminfo.
The Xen selfballoon driver accesses it within the kernel as
a built-in; this driver could potentially be loaded as a
module but currently cannot.

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.

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.

So I will ack KY's patch (I see it was just sent) but will leave
it up to Konrad and GregKH and Andrew to decide whether to
include the fragment patching the Xen selfballoon driver.

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