linux-kernel - Re: [Bug #14141] order 2 page allocation failures in iwlagn

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, 2 Oct 2009 11:11:52 +0200
From:	Frans Pop <elendil@...net.nl>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	"Pekka Enberg" <penberg@...helsinki.fi>,
	Reinette Chatre <reinette.chatre@...el.com>,
	Mel Gorman <mel@....ul.ie>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Subject: Re: [Bug #14141] order 2 page allocation failures in iwlagn

On Thursday 01 October 2009, Rafael J. Wysocki wrote:
> The following bug entry is on the current list of known regressions
> introduced between 2.6.30 and 2.6.31.  Please verify if it still should
> be listed and let me know (either way).
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14141
> Subject	: order 2 page allocation failures in iwlagn
> Submitter	: Frans Pop <elendil@...net.nl>
> Date		: 2009-09-06 7:40 (26 days old)
> References	: http://marc.info/?l=linux-kernel&m=125222287419691&w=4
> Handled-By	: Pekka Enberg <penberg@...helsinki.fi>

I'm not sure about this.

The error messages from failed allocations should now be a lot less as a 
result of this commit:
commit f82a924cc88a5541df1d4b9d38a0968cd077a051
Author: Reinette Chatre <reinette.chatre@...el.com>
Date:   Thu Sep 17 10:43:56 2009 -0700
    iwlwifi: reduce noise when skb allocation fails

That commit is in mainline, and I'm not sure if it is important enough for 
a stable update (AFAICT it's not listed for 2.6.31.2).

That commit is mostly cosmetic, but possibly the real regression is not in 
iwlagn but in the way memory is freed/defragmented. That aspect was also 
reported by Bartlomiej (#14016) and was extensively discussed (without a 
clear conclusion) here: http://lkml.org/lkml/2009/8/26/140.

My own feeling is that Bartlomiej is correct and that something has changed 
since .29 and that on average we do have less higher order areas available 
after the system has been in use for some time, but I can't substantiate 
that. I do know that before .30 I had never seen the SKB allocation 
errors.

Main problem is that it's hard to deliberately and reproducibly get the 
system in a state where the errors occur.

I certainly do feel that the kernel should try to make sure higher order 
allocations remain possible during system use. They are not only needed 
shortly after boot: drivers can be loaded/unloaded at any time. OTOH Mel 
probably does have a point that really high order GFP_ATOMIC allocations 
by drivers make no sense [1].

Anyway, I have no problems with this BR being closed.

Cheers,
FJP

[1] <20090921133704.GO12726@....ul.ie>
--
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/