Bug#883217: linux: open on NFSv4 exported file on nfs server: "Resource temporarily unavailable" under reproducible conditions when client has granted read delegation on file
Source: linux
Version: 3.16.7-ckt25-2
Severity: important
Tags: upstream
Control: fixed -1 3.18-1~exp1
[the fixed version is assuming the bisect result is right]
Hi
This was originally reported in the debian-user mailinglist at [1],
followup [2] and [3] and it might be actually a duplicate of #855632.
It sounds very simliar, so we might merge the bugs if turns to be the
case.
On a NFSv4 exported filesystem, one might see regularly "Resource
temporarily unavailable" when trying to open a file for which a client
has been granted read delegation on the file. In my case it was noted
while regularly clients access and execute a script on such export and
on server side the script needed to be updated. But simlilary as well
as in #855632's case where the file was read by a client, whilest from
another system scp'ing a new version to the server.
Steps to reproduce with minimalized customized settings (at least
tried):
root@nfs-test:~# apt-get install nfs-kernel-server
root@nfs-test:~# mkdir -p /srv/test
root@nfs-test:~# echo '/srv/test *' >> /etc/exports
root@nfs-test:~# systemctl restart nfs-kernel-server.service
root@nfs-test:~# mount localhost:/srv/test /mnt
root@nfs-test:~# grep '/mnt' /proc/mounts
localhost:/srv/test /mnt nfs4 rw,relatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp6,port=0,timeo=600,retrans=2,sec=sys,clientaddr=::1,local_lock=none,addr=::1 0 0
root@nfs-test:~#
on one terminal
root@nfs-test:~# while : ; do date >/srv/test/foo ; sleep 1 ; done
and on a second
root@nfs-test:~# while : ; do cat /mnt/foo ; sleep 1 ; done
within a couple of minutes
root@nfs-test:~# mount localhost:/srv/test /mnt
root@nfs-test:~# while : ; do date >/srv/test/foo ; sleep 1 ; done
-bash: /srv/test/foo: Resource temporarily unavailable
I tried to bisect, although in the "fixed" case it might not have been
correct that it's actually fixed, so this is more empirical result,
whereas when running a 'broken' kernel, that occured within a couple
of minutes.
----cut---------cut---------cut---------cut---------cut---------cut-----
git bisect start '--term-old' 'broken' '--term-new' 'fixed'
# broken: [754c780953397dd5ee5191b7b3ca67e09088ce7a] Merge branch 'for-v3.18' of git://git.linaro.org/people/mszyprowski/linux-dma-mapping
git bisect broken 754c780953397dd5ee5191b7b3ca67e09088ce7a
# fixed: [2d65a9f48fcdf7866aab6457bc707ca233e0c791] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux
git bisect fixed 2d65a9f48fcdf7866aab6457bc707ca233e0c791
# fixed: [5e40d331bd72447197f26525f21711c4a265b6a6] Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
git bisect fixed 5e40d331bd72447197f26525f21711c4a265b6a6
# broken: [a2ce35273c2f1aa0dcddd8822681d64ee5f31852] Merge tag 'sound-3.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect broken a2ce35273c2f1aa0dcddd8822681d64ee5f31852
# fixed: [81ae31d78239318610d7c2acb3e2610d622a5aa4] Merge tag 'stable/for-linus-3.18-rc0-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
git bisect fixed 81ae31d78239318610d7c2acb3e2610d622a5aa4
# broken: [ac0c49396d5ed9a33f08ce661635ac1bff80bb4f] Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
git bisect broken ac0c49396d5ed9a33f08ce661635ac1bff80bb4f
# broken: [e6c4efd87ab04e5ead363f24e6ac35ed3506d401] btrfs: Fix and enhance merge_extent_mapping() to insert best fitted extent map
git bisect broken e6c4efd87ab04e5ead363f24e6ac35ed3506d401
# broken: [90d0c376f5ee1927327b267faf15bf970476f09e] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs
git bisect broken 90d0c376f5ee1927327b267faf15bf970476f09e
# fixed: [6e129d00689c4d75253d1d428e82047b0aef5891] locks: flock_make_lock should return a struct file_lock (or PTR_ERR)
git bisect fixed 6e129d00689c4d75253d1d428e82047b0aef5891
# broken: [bfe8602436c803c6d5e271d52cd985d491a7470a] locks: close potential race in lease_get_mtime
git bisect broken bfe8602436c803c6d5e271d52cd985d491a7470a
# broken: [1c7dd2ff430fa14b45c9def54468e3a25ab8342b] locks: define a lm_setup handler for leases
git bisect broken 1c7dd2ff430fa14b45c9def54468e3a25ab8342b
# broken: [843c6b2f4cef384af8e0de6b7ac7191675030e3a] locks: remove i_have_this_lease check from __break_lease
git bisect broken 843c6b2f4cef384af8e0de6b7ac7191675030e3a
# fixed: [4d01b7f5e7576858b71cbaa72b541e17a229cb91] locks: give lm_break a return value
git bisect fixed 4d01b7f5e7576858b71cbaa72b541e17a229cb91
# fixed: [03d12ddf845a4eb874ffa558d65a548aee9b715b] locks: __break_lease cleanup in preparation of allowing direct removal of leases
git bisect fixed 03d12ddf845a4eb874ffa558d65a548aee9b715b
# first fixed commit: [03d12ddf845a4eb874ffa558d65a548aee9b715b] locks: __break_lease cleanup in preparation of allowing direct removal of leases
----cut---------cut---------cut---------cut---------cut---------cut-----
The above commit leads to
https://git.kernel.org/linus/03d12ddf845a4eb874ffa558d65a548aee9b715b
as the first fixing commit, but it might be here as well that more of
the previous commits are needed.
Is this worth trying to be fixed for the jessie kernel?
Regards,
Salvatore
[1] https://lists.debian.org/debian-user/2016/08/msg00022.html
[2] https://lists.debian.org/debian-user/2016/08/msg00192.html
[3] https://lists.debian.org/debian-user/2017/11/msg00920.html
Reply to: