netdev - [PATCH RFC net-next 0/2] Fix pfmemalloc in __netdev_alloc

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-next>] [day] [month] [year] [list]

Message-Id: <1408829839-20742-1-git-send-email-_govind@gmx.com>
Date:	Sun, 24 Aug 2014 03:07:17 +0530
From:	Govindarajulu Varadarajan <_govind@....com>
To:	netdev@...r.kernel.org
Cc:	davem@...emloft.net, edumazet@...gle.com, mgorman@...e.de,
	Govindarajulu Varadarajan <_govind@....com>
Subject: [PATCH RFC net-next 0/2] Fix pfmemalloc in __netdev_alloc_skb

Hi

After the introduction of skb->pfmemalloc in
c93bdd0e0:(allow skb allocation to use PFMEMALLOC reserves), skb->pfmemalloc
should be set to true if buff is allocated from reserve memory.

But in a1c7fff7e(netdev_alloc_skb() use build_skb()), netdev_alloc_skb() does
not set skb->pfmemalloc if the page is allocated from reserve memory.

Also if the page in netdev_alloc_cache->frag is allocated from reserve memory,
and if the next call to __netdev_alloc_frag does not have __GFP_MEMALLOC in
flags, we should not return a reserved memory. Because the reserve memory could
be sitting in receive queue waiting for packet to arrive. We should release
the reserve memory as soon as possible.

Is my understanding correct?

Govindarajulu Varadarajan (2):
  net: skbuff: propagate pfmemalloc to skb
  net: skbuff: do not allocate emergency memory if flags is not
    __GFP_MEMALLOC

 net/core/skbuff.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html