linux-kernel - Re: [PATCHv 2] tcp: properly initialize tcp memory limits part 2 (fix nfs regression)

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]

Date:	Sat, 3 Mar 2012 11:16:41 -0300
From:	Glauber Costa <glommer@...allels.com>
To:	Sergei Trofimovich <slyich@...il.com>
CC:	Jason Wang <jasowang@...hat.com>, <linux-kernel@...r.kernel.org>,
	<netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCHv 2] tcp: properly initialize tcp memory limits part 2
 (fix nfs regression)

On 03/02/2012 02:50 PM, Sergei Trofimovich wrote:
>>>> The change looks like a typo (division flipped to multiplication):
>>>>> limit = nr_free_buffer_pages() / 8;
>>>>> limit = nr_free_buffer_pages()<<   (PAGE_SHIFT - 10);
>>>
>>> Hi, thanks for the reporting. It's not a typo. It was previously:
>>> sysctl_tcp_mem[1]<<  (PAGE_SHIFT -  7). Looks like we need to do the
>>> limit check before shift the value. Please try the following patch, thanks.
>>
>> Still does not help. I test it by checking sha1sum of a large file over NFS
>> (small files seem to work simetimes):
>>
>>      $ strace sha1sum /gentoo/distfiles/gcc-4.6.2.tar.bz2
>>      ...
>>      open("/gentoo/distfiles/gcc-4.6.2.tar.bz2", O_RDONLY
>>      <HUNG>
>> After a certain timeout dmesg gets odd spam:
>> [  314.848094] nfs: server vmhost not responding, still trying
>> [  314.848134] nfs: server vmhost not responding, still trying
>> [  314.848145] nfs: server vmhost not responding, still trying
>> [  314.957047] nfs: server vmhost not responding, still trying
>> [  314.957066] nfs: server vmhost not responding, still trying
>> [  314.957075] nfs: server vmhost not responding, still trying
>> [  314.957085] nfs: server vmhost not responding, still trying
>> [  314.957100] nfs: server vmhost not responding, still trying
>> [  314.958023] nfs: server vmhost not responding, still trying
>> [  314.958035] nfs: server vmhost not responding, still trying
>> [  314.958044] nfs: server vmhost not responding, still trying
>> [  314.958054] nfs: server vmhost not responding, still trying
>>
>> looks like bogus messages. Might be relevant to mishandled timings
>> somewhere else or a bug in nfs code.
>
> And after 120 seconds hung tasks shows it might be an OOM issue
> Likely caused by patch, as it's a 2GB RAM +4GB swap amd64 box
> not running anything heavy:

That is a bit weird.

First because with Jason's patch, we should end up with the very same 
calculation, at the same exact order, as it was in older kernels.
Second, because by shifting << 10, you should be ending up with very 
small numbers, effectively having tcp_rmem[1] == tcp_rmem[2], and the 
same for wmem.

Can you share which numbers you end up with at 
/proc/sys/net/ipv4/tcp_{r,w}mem ?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/