From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net] net: Don't copy pfmemalloc flag in __copy_skb_header() Date: Thu, 12 Jul 2018 15:15:32 -0700 (PDT) Message-ID: <20180712.151532.651394681141690693.davem@davemloft.net> References: <93db92329a9964c336965c166e5c858cf46cd0a5.1531305883.git.sbrivio@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mgorman@suse.de, eric.dumazet@gmail.com, fw@strlen.de, ptalbert@redhat.com, netdev@vger.kernel.org To: sbrivio@redhat.com Return-path: Received: from shards.monkeyblade.net ([23.128.96.9]:43784 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732483AbeGLW1H (ORCPT ); Thu, 12 Jul 2018 18:27:07 -0400 In-Reply-To: <93db92329a9964c336965c166e5c858cf46cd0a5.1531305883.git.sbrivio@redhat.com> Sender: netdev-owner@vger.kernel.org List-ID: From: Stefano Brivio 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 > Fixes: c93bdd0e03e8 ("netvm: allow skb allocation to use PFMEMALLOC reserves") > Signed-off-by: Stefano Brivio Applied and queued up for -stable, thank you.