| 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
| ||
|
Message-ID: <a8e1da0801152155x18cfd0dcvfe638323275e539d@mail.gmail.com>
Date: Wed, 16 Jan 2008 13:55:54 +0800
From: "Dave Young" <hidave.darkstar@...il.com>
To: "Rene Herman" <rene.herman@...access.nl>
Cc: "Frans Pop" <elendil@...net.nl>, bjorn.helgaas@...com,
"Len Brown" <lenb@...nel.org>, akpm@...l.org,
cholvenstot@...cast.net, linux-kernel@...r.kernel.org,
shaohua.li@...el.com, trenn@...e.de, yakui.zhao@...el.com
Subject: Re: pnpacpi : exceeded the max number of IO resources
On Jan 9, 2008 10:47 PM, Rene Herman <rene.herman@...access.nl> wrote:
> On 09-01-08 10:34, Frans Pop wrote:
>
> Bjorn:
>
> > Len Brown wrote:
>
> >>>> Well, yes, the warning is actually new as well. Previously your kernel
> >>>> just silently ignored 8 more mem resources than it does now it seems.
> >>>>
> >>>> Given that people are hitting these limits, it might make sense to just
> >>>> do away with the warning for 2.6.24 again while waiting for the dynamic
> >>>> code?
> >>> Ping. Should these warnings be reverted for 2.6.24?
> >> No. I don't think hiding this issue again is a good idea.
> >> I'd rather live with people complaining about an addition dmesg line.
> >
> > We're not talking about "a" additional line. In my case [1] we're talking
> > about 22 (!) additional identical lines.
>
> You lucky devil. Someone else reported 92 if I remember rightly. This really
> needs to be called a 2.6.24 bug. Stick the word "regression" in the subject
> line and someone will notice...
>
> The warning might provide useful information to someone looking at a dmesg
> but given that people are hitting them way too hard with the only difference
> versus 2.6.23 being tke kernel now complaining about it, they're not useful
> enough to be printed more than once, or at more then DEBUG level or even at
> all in fact since we already know the static limit isn't enough for everyone
> and needs be turned dynamic -- really, what else is someone going to debug
> with it?
>
> I'd consider Bjorn Helgaas the PnP maintainer and he earlier agreed that
> this needed something:
>
> http://lkml.org/lkml/2007/12/5/301
>
> Printing the warning only once per type as per attached fixes the problenm
> as well.
>
> Bjorn, could you push your preference into 2.6.24?
>
>
> > Not fixing this before 2.6.24 seems completely inconsistent:
> > - either this is a real bug and the ERR level message is correct, in which
> > case the limits should be increased;
> > - or hitting the limits is harmless and the message should be changed to
> > DEBUG level.
> >
> > It is great to hear that the memory allocation will become dynamic in the
> > future and maybe that could just justify your standpoint, but having the
> > messages is damn ugly and alarming from a user point of view.
> >
> > Please keep in mind that depending on distro release schedules, 2.6.24 could
> > live for quite a bit longer than just the period needed to release 2.6.25
> > (if that is when the dynamic allocation will be implemented).
> >
> > Cheers,
> > FJP
> >
> > [1] http://lkml.org/lkml/2008/1/6/279
>
>
>
> diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c
> index 3c5eb37..cd9d4a8 100644
> --- a/drivers/pnp/pnpacpi/rsparser.c
> +++ b/drivers/pnp/pnpacpi/rsparser.c
> @@ -73,6 +73,7 @@ static void pnpacpi_parse_allocated_irqresource(struct pnp_resource_table *res,
> u32 gsi, int triggering,
> int polarity, int shareable)
> {
> + static int warned;
> int i = 0;
> int irq;
> int p, t;
> @@ -84,8 +85,9 @@ static void pnpacpi_parse_allocated_irqresource(struct pnp_resource_table *res,
> i < PNP_MAX_IRQ)
> i++;
> if (i >= PNP_MAX_IRQ) {
> - printk(KERN_ERR "pnpacpi: exceeded the max number of IRQ "
> - "resources: %d \n", PNP_MAX_IRQ);
> + if (!warned++)
> + printk(KERN_ERR "pnpacpi: exceeded the max number of IRQ "
> + "resources: %d \n", PNP_MAX_IRQ);
> return;
> }
> /*
> @@ -168,6 +170,7 @@ static void pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table *res,
> u32 dma, int type,
> int bus_master, int transfer)
> {
> + static int warned;
> int i = 0;
>
> while (i < PNP_MAX_DMA &&
> @@ -183,7 +186,7 @@ static void pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table *res,
> }
> res->dma_resource[i].start = dma;
> res->dma_resource[i].end = dma;
> - } else {
> + } else if (!warned++) {
> printk(KERN_ERR "pnpacpi: exceeded the max number of DMA "
> "resources: %d \n", PNP_MAX_DMA);
> }
> @@ -192,6 +195,7 @@ static void pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table *res,
> static void pnpacpi_parse_allocated_ioresource(struct pnp_resource_table *res,
> u64 io, u64 len, int io_decode)
> {
> + static int warned;
> int i = 0;
>
> while (!(res->port_resource[i].flags & IORESOURCE_UNSET) &&
> @@ -207,7 +211,7 @@ static void pnpacpi_parse_allocated_ioresource(struct pnp_resource_table *res,
> }
> res->port_resource[i].start = io;
> res->port_resource[i].end = io + len - 1;
> - } else {
> + } else if (!warned++) {
> printk(KERN_ERR "pnpacpi: exceeded the max number of IO "
> "resources: %d \n", PNP_MAX_PORT);
> }
> @@ -217,6 +221,7 @@ static void pnpacpi_parse_allocated_memresource(struct pnp_resource_table *res,
> u64 mem, u64 len,
> int write_protect)
> {
> + static int warned;
> int i = 0;
>
> while (!(res->mem_resource[i].flags & IORESOURCE_UNSET) &&
> @@ -233,7 +238,7 @@ static void pnpacpi_parse_allocated_memresource(struct pnp_resource_table *res,
>
> res->mem_resource[i].start = mem;
> res->mem_resource[i].end = mem + len - 1;
> - } else {
> + } else if (!warned++) {
> printk(KERN_ERR "pnpacpi: exceeded the max number of mem "
> "resources: %d\n", PNP_MAX_MEM);
> }
>
>
I noticed the port number changed to 40 in 2.6.24-rc8, but it's not
enough for me still.
Regards
dave
--
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