public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Pavel Emelyanov <xemul@parallels•com>
To: Eric Dumazet <eric.dumazet@gmail•com>
Cc: David Miller <davem@davemloft•net>, Mel Gorman <mgorman@suse•de>,
	Linux Netdev List <netdev@vger•kernel.org>,
	stable@kernel•org, Alexey Kuznetsov <kuznet@ms2•inr.ac.ru>
Subject: Re: [PATCH] skb: Propagate pfmemalloc on skb from head page only
Date: Thu, 14 Mar 2013 18:23:46 +0400	[thread overview]
Message-ID: <5141DD72.6030906@parallels.com> (raw)
In-Reply-To: <1363270569.29475.11.camel@edumazet-glaptop>

>> That said, here's the proper page->pfmemalloc propagation onto socket: we
>> must check the huge-page's head page only, other pages' pfmemalloc and mapping
>> values do not contain what is expected in this place. However, I'm not sure
>> whether this fix is _complete_, since pfmemalloc propagation via lo also 
>> oesn't look great.
>>
>> Both, bit propagation from page to skb and this check in sk_filter, were 
>> introduced by c48a11c7 (netvm: propagate page->pfmemalloc to skb), in v3.5 so
>> Mel and stable@ are in Cc.
>>
>> Signed-off-by: Pavel Emelyanov <xemul@parallels•com>
>>
>> ---
>>
>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>> index eb2106f..4e525eb 100644
>> --- a/include/linux/skbuff.h
>> +++ b/include/linux/skbuff.h
>> @@ -1292,11 +1292,13 @@ static inline void __skb_fill_page_desc(struct sk_buff *skb, int i,
>>  	 * do not lose pfmemalloc information as the pages would not be
>>  	 * allocated using __GFP_MEMALLOC.
>>  	 */
>> -	if (page->pfmemalloc && !page->mapping)
>> -		skb->pfmemalloc	= true;
>>  	frag->page.p		  = page;
>>  	frag->page_offset	  = off;
>>  	skb_frag_size_set(frag, size);
>> +
>> +	page = compound_head(page);
>> +	if (page->pfmemalloc && !page->mapping)
>> +		skb->pfmemalloc	= true;
>>  }
>>  
>>  /**
>> --
> 
> This looks a nice finding.
> 
> Note this can trigger even without vmsplice() use but regular network
> receive.

Presumably you're right, but I don't understand how :( In order to trigger
this, we should have a huge page, that gets linked to an skb _before_ it
enters the TCP receive path. How can this happen when doing sendmsg/recvmsg?

> Acked-by: Eric Dumazet <edumazet@google•com>
> 
> When I discussed with David on this issue, I said that one possibility
> would be to accept a pfmemalloc skb on regular skb if no other packet is
> in a receive queue, to get a chance to make progress (and limit memory
> consumption to no more than one skb per TCP socket)

Thanks,
Pavel

  reply	other threads:[~2013-03-14 14:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-14 13:29 [PATCH] skb: Propagate pfmemalloc on skb from head page only Pavel Emelyanov
2013-03-14 14:16 ` Eric Dumazet
2013-03-14 14:23   ` Pavel Emelyanov [this message]
2013-03-14 14:34     ` Eric Dumazet
2013-03-14 14:36       ` Pavel Emelyanov
2013-03-14 15:54   ` David Miller
2013-03-14 14:28 ` Mel Gorman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5141DD72.6030906@parallels.com \
    --to=xemul@parallels$(echo .)com \
    --cc=davem@davemloft$(echo .)net \
    --cc=eric.dumazet@gmail$(echo .)com \
    --cc=kuznet@ms2$(echo .)inr.ac.ru \
    --cc=mgorman@suse$(echo .)de \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=stable@kernel$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox