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:	Fri, 4 May 2012 10:47:21 +0800
From:	Richard Yang <weiyang@...ux.vnet.ibm.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Richard Yang <weiyang@...ux.vnet.ibm.com>,
	Wei Yang <weiyang.kernel@...il.com>, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: One problem in reassign pci bus number?

On Thu, May 03, 2012 at 01:33:17AM -0700, Yinghai Lu wrote:
>On Wed, May 2, 2012 at 11:54 PM, Richard Yang
><weiyang@...ux.vnet.ibm.com> wrote:
>> On Wed, Apr 25, 2012 at 09:28:19AM -0700, Yinghai Lu wrote:
>>>On Wed, Apr 25, 2012 at 2:47 AM, Wei Yang <weiyang.kernel@...il.com> wrote:
>>>>> busn_alloc patchset should address your concern.
>>>>>
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
>>>>> for-pci-busn-alloc
>>
>> For some functions, such as probe_resource() would you mind add some
>> comments?  Such as explain the parameter usage.
>> That would help for reading the function.
>
>I updated for-pci-busn-alloc branch with updating of probe_resource()...
>and removing bus->secondary and subordinate.
>
You mean you remove the bus->secondary field?
So the pci_bus->number hold the bus number?
I think this is a huge work.
>Please check if you can understand it ...
>
>http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commitdiff;h=7de8df57b223d54af95ffe67f8da2dd39a265971
Some question:

+static resource_size_t __find_res_top_free_size(struct resource *res,
+                                                int skip_nr)
+{
+       resource_size_t n_size;
+       struct resource tmp_res;
+
+       */
+        *   find out free number below res->end that we can use.
+        *      res->start to res->start + skip_nr - 1 can not be used.
+        */
+       n_size = resource_size(res);
+       if (n_size <= skip_nr)
+               return 0;
+
+       n_size -= skip_nr;
+       memset(&tmp_res, 0, sizeof(struct resource));
+       while (n_size > 0) {
+               int ret;
+
+               ret = __allocate_resource(res, &tmp_res, n_size,
+                       res->end - n_size + skip_nr, res->end,
+                       1, NULL, NULL, false);
+               if (ret == 0) {
+                       __release_resource(&tmp_res);
+                       break;
+               }
+               n_size--;
+       }
+
+       return n_size;
+}
So this is trying to find out the biggest free space of res?
On the right side?

For example we have , res like
   90-150
        105-140
The __find_res_top_free_size() will return 10 instead of 15. 
So this is the design decision to find the right side free resouce not
the left side?

>
>Thanks
>
>Yinghai

-- 
Richard Yang
Help you, Help me

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