linux-kernel - Re: 2.6.25-rc7-git2: Reported regressions from 2.6.24

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47ECCD17.7080908@artcom.pl>
Date:	Fri, 28 Mar 2008 11:48:55 +0100
From:	Paweł Staszewski <pstaszewski@...com.pl>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Christoph Lameter <clameter@....com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Natalie Protasevich <protasnb@...il.com>
Subject: Re: 2.6.25-rc7-git2: Reported regressions from 2.6.24

Linus Torvalds pisze:
> On Thu, 27 Mar 2008, Christoph Lameter wrote:
>   
>> Slab allocations can never use GFP_HIGHMEM.
>>     
>
> Totally irrelevant.
>
> The page allocation path does
>
>         if (gfp_flags & __GFP_ZERO)
>                 prep_zero_page(page, order, gfp_flags);
>
> and that will cause a warning REGARDLESS of whether the page is a HIGHMEM 
> page or not.
>
> And the fact is, passing in GFP_ZERO from the SLUB code is a bug 
> regardless, because it unnecessarily does the dual memset().
>
> So here's a damn big clue:
>  - SLUB does its own GFP_ZERO handling
>  - so passing GFP_ZERO down to the page allocator is a f*cking bug
>  - and this has NOTHING what-so-ever to do with GFP_HIGHMEM or even 
>    whether the warning is "valid" or not - it's a bug even if the warning 
>    had never happened.
>
> So stop blathering, and just admit that this was buggy. It was also 
> fundamentally fragile to leave GFP_ZERO around when it was known to not be 
> valid at that point (exactly because GFP_ZERO was handled by the caller).
>
> 		Linus
>
>
>   
Sorry for offtopic but i have the same problem with kernels 2.6.25-*
like:
http://kerneltrap.org/mailarchive/linux-netdev/2008/3/27/1274804
http://kerneltrap.org/mailarchive/linux-netdev/2008/3/27/1270334

I search linux-netdev and found this links.
I only sugest that 

	Denys Fedoryshchenko

can have the same problem that i have with this kernels.
I must revert my all kernels to 2.6.23.11 to get stable work on high (ip 
traffic) loads.

And there is no documentation for LRO... and Stephen Hemminger write me 
that LRO is not compatible with bridgeing and routing.
see this link:
http://bugzilla.kernel.org/show_bug.cgi?id=10335


So there must be some documentation for this ... because people can have 
many problems with this.


Sorry for offtopic but this can resolve problems like my and Denys .

Pawel

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