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:	Wed, 09 Jan 2008 15:47:48 +0100
From:	Rene Herman <rene.herman@...access.nl>
To:	Frans Pop <elendil@...net.nl>, bjorn.helgaas@...com
CC:	Len Brown <lenb@...nel.org>, akpm@...l.org,
	cholvenstot@...cast.net, hidave.darkstar@...il.com,
	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 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



View attachment "pnpacpi-rsparser-warnings.diff" of type "text/plain" (2587 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ