linux-kernel - Re: [PATCH 1/1 v4] PCI: allocate essential resources before reserving hotplug resources

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: <20110121071705.GC5009@ram-laptop>
Date:	Thu, 20 Jan 2011 23:17:05 -0800
From:	Ram Pai <linuxram@...ibm.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Ram Pai <linuxram@...ibm.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Bjorn Helgaas <bjorn.helgaas@...com>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	clemens@...isch.de, Linus Torvalds <torvalds@...ux-foundation.org>,
	peter.henriksson@...il.com, ebiederm@...stanetworks.com
Subject: Re: [PATCH 1/1 v4] PCI: allocate essential resources before
 reserving hotplug resources

On Thu, Jan 20, 2011 at 05:22:02PM -0800, Yinghai Lu wrote:
> On Wed, Jan 19, 2011 at 5:00 PM, Ram Pai <linuxram@...ibm.com> wrote:
> >    PCI: pre-allocate additional resources to devices only after successful
> >            allocation of essential resources.
> >
> >    Linux tries to pre-allocate minimal resources to hotplug bridges. This
> >    works fine as long as there are enough resources  to satisfy all other
> >    genuine resource requirements. However if enough resources are not
> >    available to satisfy any of these nice-to-have pre-allocations, the
> >    resource-allocator reports errors and returns failure.
> >
> >    This patch distinguishes between must-have resource from nice-to-have
> >    resource.  Any failure to allocate nice-to-have resources are ignored.
> >
> >    This behavior can be particularly useful to trigger automatic
> >    reallocation when the OS discovers genuine allocation-conflicts
> >    or genuine unallocated-requests caused by buggy allocation behavior
> >    of the native BIOS/uEFI.
> >
> >    https://bugzilla.kernel.org/show_bug.cgi?id=15960 captures the movitation
> >    behind the patch.
> >
> >    changelog v2:  o  fixed a bug where pci_assign_resource() was called on a
> >                      resource of zero resource size.
> >
> >    changelog v3:  addressed Bjorn's comment
> >               o  "Please don't indent and right-justify the changelog".
> >               o  removed add_size from struct resource.  The additional
> >                  size is now tracked using a linked list.
> >
> >    changelog v4:  o moved freeing up of elements of head list from
> >                  assign_requested_resources_sorted() to
> >                __assign_resources_sorted(). This fixes a corruption bug.
> >               o removed a wrong reference to 'add_size' in
> >                   pbus_size_mem(). Erroneously got introduced while
> >                   generating the patch.
> >               o some code optimizations in adjust_resources_sorted()
> >                   and assign_requested_resources_sorted()
> >
> > Signed-off-by: Ram Pai <linuxram@...ibm.com>
> >
> > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> > index 66cb8f4..efbdff2 100644
> > --- a/drivers/pci/setup-bus.c
> > +++ b/drivers/pci/setup-bus.c
> > @@ -33,11 +33,23 @@ struct resource_list_x {
> >        struct pci_dev *dev;
> >        resource_size_t start;
> >        resource_size_t end;
> > +       resource_size_t add_size;
> >        unsigned long flags;
> >  };
> >
> > -static void add_to_failed_list(struct resource_list_x *head,
> > -                                struct pci_dev *dev, struct resource *res)
> > +#define free_list(type, head) do {                      \
> > +       struct type *list, *tmp;                        \
> > +       for (list = (head)->next; list;) {              \
> > +               tmp = list;                             \
> > +               list = list->next;                      \
> > +               kfree(tmp);                             \
> > +       }                                               \
> > +       (head)->next = NULL;                            \
> > +} while (0)
> 
> inline function should be better?

I thought about it and decided to use the macro since the 'head' can
be either a resouce_list_x pointer or a resouce_list pointer.

A datastructure agonistic inline function would not be clean 
enough.

RP

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