Bug#659111: Regarding NFSv4: Save the owner/group name string when doing open
Can you please comment on wether additional fixes and/or dependencies
are needed to backport the patch below to the Debian 3.2 kernel?
The Debian kernel maintainers would prefer some feedback before applying
the fix to their 3.2 kernel.
On 04/25/2012 03:14 AM, Ben Hutchings wrote:
On Tue, 2012-04-24 at 22:04 +0200, Rik Theys wrote:
I'm experiencing the bug described in the Debian and Red Hat bug tracker.
This bug seems to have been fixed in the 3.3 kernel with your commit
From: Trond Myklebust<Trond.Myklebust@netapp.com>
Date: Sat, 7 Jan 2012 13:22:46 -0500
Subject: NFSv4: Save the owner/group name string when doing open
commit 6926afd1925a54a13684ebe05987868890665e2b upstream.
...so that we can do the uid/gid mapping outside the asynchronous RPC
This fixes a bug in the current NFSv4 atomic open code where the client
isn't able to determine what the true uid/gid fields of the file are,
(because the asynchronous nature of the OPEN call denies it the ability
to do an upcall) and so fills them with default values, marking the
inode as needing revalidation.
Unfortunately, in some cases, the VFS will do some additional sanity
checks on the file, and may override the server's decision to allow
the open because it sees the wrong owner/group fields.
Signed-off-by: Trond Myklebust<Trond.Myklebust@netapp.com>
Signed-off-by: Jonathan Nieder<firstname.lastname@example.org>
It seems Red Hat will apply the patch in their RHEL 6.3 kernel. I would
also like to see this patch included in the upcoming Debian 7.0 kernel,
which is based on kernel 3.2.
I would like to propose this patch for a stable kernel update
(3.2.x and/or 3.0.x). Trond, do you agree that this patch (alone)
can/should be part of a stable update? The Debian maintainers would
prefer to see the patch be part of a stable update to consider it.
Note that this is not a *requirement* for the Debian kernel package.
But we do prefer to get backported bug fixes reviewed and tested through
the stable process, and shared with other distributions in this way.
Now that I've finally had a look at this patch - and I'm sorry it's
taken this long, but I do have a *lot* of different bugs and patches to
- With my 3.2-stable maintainer hat on, I'm going to follow Greg's
judgement and say this isn't suitable.
- With my Debian kernel team hat on, I think this is probably OK, but
I'd like to see Trond comment on whether he's aware of any dependencies
or further fixes likely to be needed.
Senior System Engineer
KU Leuven - Dept. Elektrotechniek (ESAT)
Kasteelpark Arenberg 10
B-3001 LEUVEN - HEVERLEE
<<Any errors in spelling, tact or fact are transmission errors>>