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: <alpine.DEB.2.00.0906180935130.2894@chino.kir.corp.google.com>
Date:	Thu, 18 Jun 2009 09:56:14 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	David Miller <davem@...emloft.net>
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

On Wed, 17 Jun 2009, David Miller wrote:

> From: Eric Dumazet <eric.dumazet@...il.com>
> Date: Thu, 18 Jun 2009 00:30:58 +0200
> 
> > My point is that 99% of callers know allocation failures are
> > recoverable.
> 
> I agree that, surely for GFP_ATOMIC, warnings should be off
> by default.
> 

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.

GFP_ATOMIC allocations are allowed to access memory deeper in zone 
watermarks so that they are more likely to succeed; page allocation 
failure messages indicate that the system is either completely oom or that 
there is a serious VM bug.

Defining GFP_ATOMIC as (__GFP_HIGH | __GFP_NOWARN) would also require the 
bit to be masked off if page allocation failure messages should be 
emitted.  GFP_ATOMIC | GFP_DMA allocations become
(GFP_ATOMIC | GFP_DMA) & ~__GFP_NOWARN, for example.  This is not normally 
how GFP_* macros are composed from __GFP_* bits because of the increasing 
complexity.

It's again my opinion that allocators that can recover ("recover" used 
here in the sense of simply delaying an ack such as the ipv4 case 
discussed earlier, for example) without side effects (like a failed 
syscall) should specify __GFP_NOWARN.

Page allocation failures have emitted warnings for all gfp masks without 
__GFP_NOWARN since 2.5.53 over six and a half years ago.
--
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/