linux-kernel - Re: GFP_ATOMIC page 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]

Date:	Wed, 02 Apr 2008 19:00:25 +0900
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	David Miller <davem@...emloft.net>
Cc:	kosaki.motohiro@...fujitsu.com, akpm@...ux-foundation.org,
	csnook@...hat.com, davej@...emonkey.org.uk,
	nickpiggin@...oo.com.au, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, Michael Chan <mchan@...adcom.com>
Subject: Re: GFP_ATOMIC page allocation failures.

Hi

> > if network guys hope known-good driver should call 
> > __netdev_alloc_skb(dev, length, GFP_ATOMIC|__GFP_NOWARN) instead netdev_alloc_skb,
> > I think we should make netdev_alloc_skb_nowarn.
> 
> Giving it a proper name like this takes away the indication that this
> situation is very special.

Hmmm,

at least, tg3 driver often output the same message on my test environment.
(because I often run stress test ;)
I doubt almost driver has the same problem under heavy workload.

and I think tg3 is known-good driver too.
because its alloc failure doesn't cause any bad thing at all.

Do you favorite the following patch?


---------------------------------------------------------------------
We get rather a lot of reports of page allocation warnings coming out of
tg3.  But this driver is know to handle them properly so let's suppress
them.

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
CC: David Miller <davem@...emloft.net>
CC: Andrew Morton <akpm@...ux-foundation.org>
CC: Michael Chan <mchan@...adcom.com>
---
 drivers/net/tg3.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

Index: b/drivers/net/tg3.c
===================================================================
--- a/drivers/net/tg3.c 2008-03-14 21:38:12.000000000 +0900
+++ b/drivers/net/tg3.c 2008-04-02 18:54:15.000000000 +0900
@@ -307,6 +307,11 @@ static const struct {
        { "interrupt test (offline)" },
 };

+static inline void *tg3_alloc_skb(struct net_device *dev, unsigned int length)
+{
+       return __netdev_alloc_skb(dev, length, GFP_ATOMIC|__GFP_NOWARN);
+}
+
 static void tg3_write32(struct tg3 *tp, u32 off, u32 val)
 {
        writel(val, tp->regs + off);
@@ -3437,7 +3442,7 @@ static int tg3_alloc_rx_skb(struct tg3 *
         * Callers depend upon this behavior and assume that
         * we leave everything unchanged if we fail.
         */
-       skb = netdev_alloc_skb(tp->dev, skb_size);
+       skb = tg3_alloc_skb(tp->dev, skb_size);
        if (skb == NULL)
                return -ENOMEM;
@@ -3609,7 +3614,7 @@ static int tg3_rx(struct tg3 *tp, int bu
                        tg3_recycle_rx(tp, opaque_key,
                                       desc_idx, *post_ptr);

-                       copy_skb = netdev_alloc_skb(tp->dev, len + 2);
+                       copy_skb = tg3_alloc_skb(tp->dev, len + 2);
                        if (copy_skb == NULL)
                                goto drop_it_no_recycle;

@@ -9370,7 +9375,7 @@ static int tg3_run_loopback(struct tg3 *
        err = -EIO;

        tx_len = 1514;
-       skb = netdev_alloc_skb(tp->dev, tx_len);
+       skb = tg3_alloc_skb(tp->dev, tx_len);
        if (!skb)
                return -ENOMEM;


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