linux-kernel - Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

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]

Date:	Mon, 28 Jan 2008 15:31:42 -0700
From:	Matthew Wilcox <matthew@....cx>
To:	Greg KH <greg@...ah.com>
Cc:	Tony Camuso <tcamuso@...hat.com>,
	Grant Grundler <grundler@...isc-linux.org>,
	Loic Prylli <loic@...i.com>, Adrian Bunk <bunk@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	Jeff Garzik <jeff@...zik.org>,
	linux-pci@...ey.karlin.mff.cuni.cz, Martin Mares <mj@....cz>
Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Mon, Jan 28, 2008 at 12:44:31PM -0800, Greg KH wrote:
> On Mon, Jan 28, 2008 at 01:32:06PM -0500, Tony Camuso wrote:
> > Greg,
> >
> > Have you given Grant's suggestion any further consideration?
> >
> > I'd like to know how the MMCONFIG issues discussed in this thread are going
> > to be handled upstream. I have a patch implemented in RHEL 5.2, but I would
> > rather have the upstream patch implemented, whatever it is.
> 
> Well, everyone still doesn't seem to agree on the proper way forward
> here, so for me to just "pick one" isn't very appropriate.
> 
> So, can we try again?
> 
> Can people submit, what they think the change should be?  Right now I
> have Arjan's patch in my kernel tree, but will not send it to Linus for
> .25 for now, unless everyone thinks that is the best solution at the
> moment (which, for me, I'm leaning toward right now...)

My opinion is that Ivan's patch followed by my patch is the best way
forward.  I see Arjan's patch as a good prototype, but it introduces a lot
of unnecessary infrastructure (and a userspace interface that I dislike).

I would like to see Ivan's patch merged ASAP as it does fix one of
my machines.  akpm has the patch from me to disable io decoding, and
intends to send it to Linus during this merge window ... that patch
becomes unnecessary if we merge Ivan's patch.

My patch is an incremental improvement that adds some of the features
of Arjan's patch without the extra infrastructure.  I don't think it's
urgent, but it does make some of our internal interfaces cleaner.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/