Re: [gentoo-user] NFS kernel bug

[Tom Wijsman]

On Sun, 08 Dec 2013 16:13:26 -0500
Tanstaafl <tanstaafl@×××××××××××.org> wrote:

> On 2013-10-26 6:19 PM, Daniel Frey <djqfrey@×××××.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  : TomWij@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D