linux-kernel - Re: [PATCH 01/11] mm: export vmalloc_sync

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: <20111201230007.GE3716@kroah.com>
Date:	Thu, 1 Dec 2011 15:00:07 -0800
From:	Greg KH <greg@...ah.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	devel@...verdev.osuosl.org, lttng-dev@...ts.lttng.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>, David Howells <dhowells@...hat.com>,
	David McCullough <davidm@...pgear.com>,
	D Jeff Dionne <jeff@...inux.org>,
	Greg Ungerer <gerg@...pgear.com>,
	Paul Mundt <lethal@...ux-sh.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/11] mm: export vmalloc_sync_all symbol to GPL modules

On Thu, Dec 01, 2011 at 05:28:03PM -0500, Christoph Hellwig wrote:
> On Thu, Dec 01, 2011 at 02:13:37PM -0800, Greg KH wrote:
> > On Thu, Dec 01, 2011 at 04:57:00PM -0500, Christoph Hellwig wrote:
> > > On Thu, Dec 01, 2011 at 04:41:13PM -0500, Mathieu Desnoyers wrote:
> > > > LTTng needs this symbol exported. It calls it to ensure its tracing
> > > > buffers and allocated data structures never trigger a page fault. This
> > > > is required to handle page fault handler tracing and NMI tracing
> > > > gracefully.
> > > 
> > > We:
> > > 
> > >  a) don't export symbols unless they have an intree-user
> > 
> > lttng is now in-tree in the drivers/staging/ area.  See linux-next for
> > details if you are curious.
> 
> Eww - merging stuff without discussion on lkml is more than evil.

Do you really want discussing all staging driver crap on lkml?

Core changes, like this one, for stuff in staging should be done on
lkml, which is what this conversation is :)

> Either way, it was guaranteed that drivers/staging is considered out of
> tree for core code.

The zram and zcache code would tend to disagree with you there :)

> I'm defintively dead set against exporting anything for staging and
> opening that slippery slope.

How else should we handle something like this then?  Some code, this one
specifically, is trying to get merged, so taking it slowly, through
staging, and getting it reviewed and cleaned up better before it can go
into the "real" part of the kernel, is the whole goal here.

Here's a real need for a symbol that an existing, shipping, useful
kernel module is wanting to use.

If you can provide a way that this can be handled without such an
export, that does not require digging through the symbol table (which is
what it was doing and I rightfully objected to that), then please let us
know.

Otherwise, what are our alternatives here, to just forbid this code from
ever being merged?

thanks,

greg k-h
--
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/