linux-kernel - Re: [patch] ipv4: don't warn about skb ack allocation failures

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]

Message-Id: <20090618.123708.78849607.davem@davemloft.net>
Date:	Thu, 18 Jun 2009 12:37:08 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	rientjes@...gle.com
Cc:	eric.dumazet@...il.com, jpiszcz@...idpixels.com,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] ipv4: don't warn about skb ack allocation failures

From: David Rientjes <rientjes@...gle.com>
Date: Thu, 18 Jun 2009 12:23:28 -0700 (PDT)

> On Thu, 18 Jun 2009, David Miller wrote:
> 
>> > I disagree, page allocation failure messages show vital information about 
>> > the state of the VM so that we can find bugs and GFP_ATOMIC allocations 
>> > are the most common trigger for these diagnostic messages since 
>> > __GFP_WAIT allocations can trigger direct reclaim (and __GFP_FS 
>> > allocations can trigger the oom killer) to free memory and will retry the 
>> > allocation if ~__GFP_NORETRY.
>> 
>> It's COMPLETELY and ABSOLUTELY normal for GFP_ATOMIC allocations to
>> fail in the networking.
>> 
> 
> __GFP_NOWARN exists for that reason.

You're going to have to put that into every driver, every part of
the core networking, every protocol.

That's dumb.

> I understand what you're trying to avoid, but I disagree with the
> approach of altering the default behavior of GFP_ATOMIC.

The default got changed at some point because it never did
crap like this before.

> I may suggest that emitting the page allocation failures become a
> compile time option; CONFIG_DEBUG_VM would be my suggestion.

Use statistics gathering and tracing for this, not log spam.

It serves all of your needs without spewing junk into the log.  It
allows complete diagnosis and gathering of whatever information you
may need.
--
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/