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-next>] [day] [month] [year] [list]
Date:	Wed, 13 Apr 2016 19:28:41 +0800
From:	Ding Tianhong <dingtianhong@...wei.com>
To:	<linux-nfs-approval@...r.kernel.org>, <tom@...bertland.com>,
	Netdev <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	<dhowells@...hat.com>, <viro@...iv.linux.org.u>,
	<chuck.lever@...cle.com>
Subject: [RFC] Is it a bug for nfs on udp6 mode or kernel?

Hi everyone:

I have met this problem when I try to test udp6 for nfs connection, my environment is:

Server:
kernel: 4.1.15
IP:xxxx::36/64
MTU:1500
Setting: /etc/exports:/home/nfs *(rw,sync,no_subtree_check,no_root_squash)

Client:
kernel: 4.1.18
IP:xxxx::90/64
MTU:1500
command: mount -t nfs -o vers=3,proto=udp6,rsize=4096,wsize=4096 [xxxx::36]:/home/nfs /home/tmp

I check the nfs parameter configuration, it looks fine and could work well for proto=tcp6.

Then I have mount correctly and try to run the command "ls", it hang.

When I use the rsize=1024 and wsize=1024 to mount, the problem disappeared, so I guess it is the problem for GSO or GRO for UDP。

Then I try to debug the problem, first I tcpdump the package from cline to server, and found that
the client have send readdirplus message to server correctly, and then the Server send a 4k package
to client(the big package will frag to 4 package by GSO), till now it looks fine, and the Client Nic could
receive the 4 skb then send to upper stack to ipv6 and udp, I found the incoming 4 package has been merged
to one and send to upper stack just like sunrpc, but I try to open the rpc_debug, it looks that the rpc could
not receive message.


I built a simple demo to test the udp stack, use the client socket to send big package to server socket, it work well,
so I think the udp is fine, maybe the bug is in sunrpc.

The test is very simple, does any body met the same problem like me, thanks for any suggestion.

Ding 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ