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]
Message-ID: <737a947e-a53d-fcd2-bbc3-ca373bea6cb1@huawei.com>
Date:   Tue, 15 May 2018 11:47:46 +0800
From:   maowenan <maowenan@...wei.com>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        <jlayton@...nel.org>, <linux-nfs@...r.kernel.org>
CC:     <yangerkun@...wei.com>, "weiyongjun (A)" <weiyongjun1@...wei.co>
Subject: mounting NFS on the same host leads to D state

Hi,

Recently I have tested NFS and exportfs scenario,
that NFS server and client are in the same host.
And I found mounting NFS filesystm onto the same host
can lead to rpc.mountd and related task become D state.
My kernel version is based on 3.10, and I find 4.15 has the same
appearance.

My test step as below:
1)create dir.
mkdir -p /home/test1 /home/test2
2)share dir /home/test1
echo '/home/test1 localhost(rw,all_squash,anonuid=0,anongid=0)' > /etc/exports
3)exportfs
exportfs -vr || echo "Failed to export /home/test1"
4)mount NFS.
mount localhost:/home/test1 /home/test2 -o vers=3,soft
5)share dir /home/test2
echo '/home/test2 *(rw,all_squash,anonuid=0,anongid=0)' >> /etc/exports
6)exportfs
exportfs -vr
7) list /home/test2
ls /home/test2
then we found ls command is hung, ls and rpc.mountd became "D" state, and after
180 second ls command return.

Another scenario as below:
1)create dir.
mkdir -p /home/test3 /home/test4
2)share dir /home/test3
echo '/home/test3 localhost(rw,sync,no_wdelay,anonuid=0,anongid=0,no_subtree_check)' > /etc/exports
3)exportfs
exportfs -r
4)to see NFS status
showmount -e localhost
5)mount NFS
mount -t nfs4 -o proto=tcp,nolock,soft,timeo=50 localhost:/home/test3 /home/test4
6) stop nfs service,and  and check ls task state is D.
service nfs stop
ls /home/test4
ls command is hung and became D state.

I wonder to know is it reasonable about these test scenario because NFS server and
client are in the same host? Since some task went into D state, is there any reason about this?
and is there any patch to fix this issue?
Here is a link to talk about NFS mounting on the same host,  https://lwn.net/Articles/595652/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ