[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20180712.151532.651394681141690693.davem@davemloft.net>
Date: Thu, 12 Jul 2018 15:15:32 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: sbrivio@...hat.com
Cc: mgorman@...e.de, eric.dumazet@...il.com, fw@...len.de,
ptalbert@...hat.com, netdev@...r.kernel.org
Subject: Re: [PATCH net] net: Don't copy pfmemalloc flag in
__copy_skb_header()
From: Stefano Brivio <sbrivio@...hat.com>
Date: Wed, 11 Jul 2018 14:39:42 +0200
> The pfmemalloc flag indicates that the skb was allocated from
> the PFMEMALLOC reserves, and the flag is currently copied on skb
> copy and clone.
>
> However, an skb copied from an skb flagged with pfmemalloc
> wasn't necessarily allocated from PFMEMALLOC reserves, and on
> the other hand an skb allocated that way might be copied from an
> skb that wasn't.
>
> So we should not copy the flag on skb copy, and rather decide
> whether to allow an skb to be associated with sockets unrelated
> to page reclaim depending only on how it was allocated.
>
> Move the pfmemalloc flag before headers_start[0] using an
> existing 1-bit hole, so that __copy_skb_header() doesn't copy
> it.
>
> When cloning, we'll now take care of this flag explicitly,
> contravening to the warning comment of __skb_clone().
>
> While at it, restore the newline usage introduced by commit
> b19372273164 ("net: reorganize sk_buff for faster
> __copy_skb_header()") to visually separate bytes used in
> bitfields after headers_start[0], that was gone after commit
> a9e419dc7be6 ("netfilter: merge ctinfo into nfct pointer storage
> area"), and describe the pfmemalloc flag in the kernel-doc
> structure comment.
>
> This doesn't change the size of sk_buff or cacheline boundaries,
> but consolidates the 15 bits hole before tc_index into a 2 bytes
> hole before csum, that could now be filled more easily.
>
> Reported-by: Patrick Talbert <ptalbert@...hat.com>
> Fixes: c93bdd0e03e8 ("netvm: allow skb allocation to use PFMEMALLOC reserves")
> Signed-off-by: Stefano Brivio <sbrivio@...hat.com>
Applied and queued up for -stable, thank you.
Powered by blists - more mailing lists