linux-kernel - RE: [PATCH 1/3] drivers:pnp Add support for descendants claiming memory address space

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]

Date:	Thu, 19 Mar 2015 19:21:53 +0000
From:	Jake Oshins <jakeo@...rosoft.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"olaf@...fle.de" <olaf@...fle.de>
CC:	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	KY Srinivasan <kys@...rosoft.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"apw@...onical.com" <apw@...onical.com>,
	"vkuznets@...hat.com" <vkuznets@...hat.com>,
	Linux ACPI <linux-acpi@...r.kernel.org>,
	Linux PCI <linux-pci@...r.kernel.org>,
	"Bjorn Helgaas" <bhelgaas@...gle.com>
Subject: RE: [PATCH 1/3] drivers:pnp Add support for descendants claiming
 memory address space

> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@...ysocki.net]
> Sent: Tuesday, March 10, 2015 5:34 PM
> To: Jake Oshins; olaf@...fle.de
> Cc: Rafael J. Wysocki; gregkh@...uxfoundation.org; KY Srinivasan; linux-
> kernel@...r.kernel.org; apw@...onical.com; vkuznets@...hat.com; Linux
> ACPI; Linux PCI; Bjorn Helgaas
> Subject: Re: [PATCH 1/3] drivers:pnp Add support for descendants claiming
> memory address space
> 

<snip>

> It seems to me then that what you really want is a null protocol for PNP
> which simply doesn't do anything.  I don't see any justification for the
> "descendant_protocol" name.  It's just a null one.
> 
> In that case you should slightly modify the PNP bus type to be able to
> use a null protocol without defining the stub ->get, ->put and ->disable
> methods that just do nothing and return 0.
> 
> Then, you can define the null protocol without any methods in
> drivers/pnp/core.c and use it in your code without adding the "descendant"
> concept.
> 
> Of course, that comes with a price which is that every device using the
> null protocol will have that protocol's abstract device as its parent.
> I suppose that this is not a problem?
> 

<snip>

> 
> > The problem comes in if there are PCI devices in the same region.  There's
> no
> > easy way to figure out whether the claim conflicts with the PCI devices,
> since
> > the PCI device's claims are made through the pnp layer.
> 
> Well, please look at __pci_request_region() then and tell me where it uses
> the
> PNP layer.
> 

I've been thinking a lot (and poking around in the code, trying things) in response to what you wrote, and in particular in response to the two parts quoted above.  Having a null protocol where each of the devices has the same abstract parent doesn't serve my needs, because it won't guarantee that the ranges claimed fall within the _CRS of the grandparent or great-grandparent node.  And, in fact, I don't think that my proposed patch is actually accomplishing that deterministically either, at the moment.

Your response, at length, convinced me to look at things differently and I realized that I wasn't getting as much from this approach as I thought I was.  I'd like to withdraw this patch series.  I can come up with an alternative solution that exists only within the Hyper-V-related drivers.

Thanks again for your time and patience,
Jake Oshins