linux-kernel - Re: [PATCH]: PNP: Increase the value of PNP constant

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:	Fri, 16 Nov 2007 13:46:37 -0700
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Rene Herman <rene.herman@...access.nl>
Cc:	Zhao Yakui <yakui.zhao@...el.com>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, shaohua.li@...el.com,
	Thomas Renninger <trenn@...e.de>
Subject: Re: [PATCH]: PNP: Increase the value of PNP constant

On Friday 16 November 2007 09:52:48 am Rene Herman wrote:
> On 16-11-07 08:39, Zhao Yakui wrote:
> 
> > Subject: PNP: Increase the value of PNP constant
> > From: Zhao Yakui  <yakui.zhao@...el.com>
> > 
> > On some systems the number of resources(IO,MEM) returnedy by PNP
> > device is greater than the PNP constant, for example motherboard devices. 
> > It brings that some resources can't be reserved and resource confilicts.
> > This will cause PCI resources are assigned wrongly in some systems, and
> > cause hang. This is a regression since we deleted ACPI motherboard
> > driver and use PNP system driver.
> > 
> > Andrew, I thought this is an urgent issue and should be fixed ASAP, and
> > this is a good candidate for -stable tree

Thomas Renninger is working on PNP patches so we can accomodate any
number of resources.  We had talked about an interim solution like
the one Shaohua is proposing, but thought the space overhead was
objectionable:

I (Bjorn) wrote:
> ...  We're going from 16 resource structs
> per PNP device to 42.  Each struct resource looks like about 7
> longs or pointers, so on a 32-bit system with 16 PNP devices, we
> are going from about 7K to almost 19K just for these tables, most
> of which are mostly empty.  On a 64-bit system, it goes from about
> 14K to over 37K.

However, we did not realize that switching from the ACPI motherboard
driver to the PNP driver would cause a regression.  Since that's the
case, I don't think we have much choice -- I think we have to either
increase the table sizes until we can handle things dynamically, or
switch back to the ACPI motherboard driver until we have Thomas's
work.  For a -stable patch, I think enlarging the tables is safer.

The space analysis above was based on increasing PNP_MAX_PORT from
8 to 32 and PNP_MAX_IRQ from 2 to 4 (total increase of 26 resources
per device).  Shaohua's patch adds 16 port and 8 mem resources for
an increase of 24, so will use slightly less space.

Acked-by: Bjorn Helgaas <bjorn.helgaas@...com>

> > Signed-off-by: Li Shaohua <shaohua.li@...el.com>
> > Signed-off-by: Zhao Yakui <yakui.zhao@...el.com>
> > 
> > ---
> >  drivers/pnp/pnpacpi/rsparser.c |   18 ++++++++++++++++--
> >  include/linux/pnp.h            |    4 ++--
> >  2 files changed, 18 insertions(+), 4 deletions(-)
> > 
> > Index: linux-2.6.24-rc2/include/linux/pnp.h
> > ===================================================================
> > --- linux-2.6.24-rc2.orig/include/linux/pnp.h
> > +++ linux-2.6.24-rc2/include/linux/pnp.h
> > @@ -13,8 +13,8 @@
> >  #include <linux/errno.h>
> >  #include <linux/mod_devicetable.h>
> >  
> > -#define PNP_MAX_PORT		8
> > -#define PNP_MAX_MEM		4
> > +#define PNP_MAX_PORT		24
> > +#define PNP_MAX_MEM		12
> 
> This fairly significantly grows (for example?) a struct pnp_resource_table. 
> Are 24 and 12 really sensible?
> 
> Rene.

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