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: <CAErSpo5_9N-HX3Ja8k04QaS6nss8SAm-NUtuQyHt0t-Dczt8-w@mail.gmail.com>
Date:	Sun, 12 Feb 2012 15:51:20 -0800
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Tony Luck <tony.luck@...el.com>,
	Dominik Brodowski <linux@...inikbrodowski.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org
Subject: Re: [PATCH 04/24] PCI: Add busn_res operation functions

On Mon, Feb 6, 2012 at 12:45 PM, Yinghai Lu <yinghai@...nel.org> wrote:
> On Mon, Feb 6, 2012 at 10:59 AM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
>> On Sat, Feb 4, 2012 at 10:57 PM, Yinghai Lu <yinghai@...nel.org> wrote:
>>> will use them insert/update busn res in pci_bus
>>>
>>> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
>>> ---
>>>  drivers/pci/probe.c |   42 ++++++++++++++++++++++++++++++++++++++++++
>>>  include/linux/pci.h |    3 +++
>>>  2 files changed, 45 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>>> index a114173..8d4de5e 100644
>>> --- a/drivers/pci/probe.c
>>> +++ b/drivers/pci/probe.c
>>> @@ -1622,6 +1622,48 @@ err_out:
>>>        return NULL;
>>>  }
>>>
>>> +void pci_bus_insert_busn_res(struct pci_bus *b, int bus, int bus_max)
>>> +{
>>> +       struct resource *res = &b->busn_res;
>>> +       struct resource *parent_res = &iobusn_resource;
>>> +       int ret;
>>> +
>>> +       res->start = busn(pci_domain_nr(b), bus);
>>> +       res->end = busn(pci_domain_nr(b), bus_max);
>>> +       res->flags = IORESOURCE_BUS;
>>> +
>>> +       if (!pci_is_root_bus(b))
>>> +               parent_res = &b->parent->busn_res;
>>> +
>>> +       ret = insert_resource(parent_res, res);
>>> +
>>> +       dev_printk(KERN_DEBUG, &b->dev,
>>> +                       "busn_res: %pR %s inserted under %pR\n",
>>> +                       res, ret ? "can not be" : "is", parent_res);
>>> +}
>>> +
>>> +void pci_bus_update_busn_res_end(struct pci_bus *b, int bus_max)
>>> +{
>>> +       struct resource *res = &b->busn_res;
>>> +       struct resource old_res = *res;
>>> +
>>> +       res->end = busn_update_bus_nr(res->end, bus_max);
>>
>> I think this design is a mistake.  Here's what you're doing:
>>
>>  - initialize struct resource (keys are "start" and "end")
>>  - insert into tree (placed in tree by kernel/resource.c based on
>> "start" and "end")
>>  - update "end"
>>
>> You "know" in this case that the update is safe because the caller has
>> validated "bus_max."  But that still breaks the kernel/resource.c
>> encapsulation.  If we change the kernel/resource.c implementation,
>> this code might break.
>
> the point is: I only want to reuse allocate_resource() to get right position.
> and the code does not depends to kernel/resource.c much.
>
>>
>> I think it would be better to remove the bus resource from the tree,
>> change its "end," then re-insert it.
>
> how about parent buses that have extended top?

I don't understand your question.  I assume you mean there's a case
where remove/update/reinsert doesn't work, but I don't see why that
would be a problem.  Can you show an example?
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ