On Sun, 08 Dec 2013 16:13:26 -0500 Tanstaafl <tansta...@libertytrek.org> wrote:
> On 2013-10-26 6:19 PM, Daniel Frey <djqf...@gmail.com> wrote: > > Just a note to other NFS server users - > > > > There's a kernel bug that can cause unmounting an NFS share to > > segfault (and not actually unmount anything.) > > > > I had in in the kernel 3.10 version, perhaps even before that as I > > don't update the kernel on my mythtv backend server that often. > > > > It hangs the shutdown process with an oops and it will require > > physical manual intervention to shut the machine down. > > > > If you upgrade to 3.11.5 or greater the problem goes away. > > > > I've been banging my head against the wall with this for over a > > week and *finally* found a resolution after going through a lot of > > NFS searches via Google. > > So... is this fixed in the stable 3.10 series (ie, 3.10.7 or 3.10.17)? TL;DR: One of both NFS fixes from 3.11.5 is fixed since v3.10.16, the other one is fixed since v3.11.5; porting the other one back does not appear easy, because different code is present (or an alternative fix). == Which commits? == http://thread.gmane.org/gmane.linux.kernel/1577607 mentions: 1. NFSv4.1: nfs4_fl_prepare_ds - fix bugs when the connect attempt fails 2. nfsd4: fix leak of inode reference on delegation failure == Are they present in v3.10.17? == For (1) we see that http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?id=v3.10.17&qt=grep&q=nfs4_fl_prepare_ds does show the commit. For (2) we see that http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?id=v3.10.17&qt=grep&q=fix%20leak%20of%20inode does not show the commit. So, one of both commits is fixed in 3.10.17, the other is not. == Which versions contain these commits? == We can find all relevant commits IDs by searching for the commit message in the last release of each branch; then we just enumerate all tags, which gives us the versions where the commit is present. Checking the upstream commits yields: $ git tag --contains 52b26a3e1bb3e065c32b3febdac1e1f117d88e15 # (1) v3.12 v3.12-rc4 v3.12-rc5 v3.12-rc6 v3.12-rc7 v3.12.1 v3.12.2 v3.12.3 v3.12.4 v3.13-rc1 v3.13-rc2 v3.13-rc3 $ git tag --contains bf7bd3e98be5c74813bee6ad496139fb0a011b3b # (2) v3.12 v3.12-rc1 v3.12-rc2 v3.12-rc3 v3.12-rc4 v3.12-rc5 v3.12-rc6 v3.12-rc7 v3.12.1 v3.12.2 v3.12.3 v3.12.4 v3.13-rc1 v3.13-rc2 v3.13-rc3 Checking the ported back 3.11 commits yields: $ git tag --contains 3b12032f89e27f139828bad8120149b1584bc898 # (1) v3.11.5 v3.11.6 v3.11.7 v3.11.8 v3.11.9 v3.11.10 $ git tag --contains ba3460519e393d0f212403ae3535305f423d84ed # (2) v3.11.5 v3.11.6 v3.11.7 v3.11.8 v3.11.9 v3.11.10 Checking the ported back 3.10 commit yields: $ git tag --contains 28f7ae257183e8064119db486190d2229caae369 # (1) v3.10.16 v3.10.17 v3.10.18 v3.10.19 v3.10.20 v3.10.21 v3.10.22 v3.10.23 This summarizes all versions where these two commits are available. == Only one of both is available in v3.10.17, can I apply the other? == It appears that (2) can't be applied to v3.10 without porting it back; or maybe it has already applied, but in a quite different way. == Which versions contain the bad commit(s)? Which one are affected? == A list of all versions that contain the bad commit of (2) are: $ git tag --contains 68a3396178e6688ad7367202cdf0af8ed03c8727 | tr '\n' ' ' v3.10 v3.10-rc1 v3.10-rc2 v3.10-rc3 v3.10-rc4 v3.10-rc5 v3.10-rc6 v3.10-rc7 v3.10.1 v3.10.10 v3.10.11 v3.10.12 v3.10.13 v3.10.14 v3.10.15 v3.10.16 v3.10.17 v3.10.18 v3.10.19 v3.10.2 v3.10.20 v3.10.21 v3.10.22 v3.10.23 v3.10.3 v3.10.4 v3.10.5 v3.10.6 v3.10.7 v3.10.8 v3.10.9 v3.11 v3.11-rc1 v3.11-rc2 v3.11-rc3 v3.11-rc4 v3.11-rc5 v3.11-rc6 v3.11-rc7 v3.11.1 v3.11.10 v3.11.2 v3.11.3 v3.11.4 v3.11.5 v3.11.6 v3.11.7 v3.11.8 v3.11.9 v3.12 v3.12-rc1 v3.12-rc2 v3.12-rc3 v3.12-rc4 v3.12-rc5 v3.12-rc6 v3.12-rc7 v3.12.1 v3.12.2 v3.12.3 v3.12.4 v3.13-rc1 v3.13-rc2 v3.13-rc3 Excluding wherever it is fixed, only v3.10-rc1 - v3.10.23 are affected. As the first commit doesn't mention where it regressed, I cannot check in which versions that bad commit is present for (1); though it is definitely limited to versions lower than v3.10.16 as evidenced earlier. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
