netdev - Re: [PATCH] skb: Propagate pfmemalloc on skb from head page only

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]

Message-ID: <5141DD72.6030906@parallels.com>
Date:	Thu, 14 Mar 2013 18:23:46 +0400
From:	Pavel Emelyanov <xemul@...allels.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	David Miller <davem@...emloft.net>, Mel Gorman <mgorman@...e.de>,
	Linux Netdev List <netdev@...r.kernel.org>,
	stable@...nel.org, Alexey Kuznetsov <kuznet@....inr.ac.ru>
Subject: Re: [PATCH] skb: Propagate pfmemalloc on skb from head page only

>> 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@...allels.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@...gle.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
--
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