Subject : nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
Submitter : Paul Collins <email@example.com>
Date : 2008-08-02 12:03
References : http://marc.info/?l=linux-kernel&m=121767906702209&w=4
This entry is being used for tracking a regression from 2.6.26. Please don't
close it until the problem is fixed in the mainline.
Handled-By : "J. Bruce Fields" <firstname.lastname@example.org>
On Sunday, 3 of August 2008, Paul Collins wrote:
> Paul Collins <email@example.com> writes:
> > "J. Bruce Fields" <firstname.lastname@example.org> writes:
> >> On Sun, Aug 03, 2008 at 12:03:18AM +1200, Paul Collins wrote:
> >>> I just got the oops below on a ppc32 NFS4 server. I was cross-compiling
> >>> Linux with an amd64 client at the time. The server is running Linus's
> >>> tree as of 94ad374a0751f40d25e22e036c37f7263569d24c, the client is
> >>> running 2.6.26.
> >>> The server's kernel was cross-compiled with gcc 4.2.4-3 and binutils
> >>> 184.108.40.20680610-1, both built from the Debian sources following their
> >>> toolchain-building procedures.
> >> Without having really thought about this,
> >> 496d6c32d4d057cb44272d9bd587ff97d023ee92 "nfsd: fix spurious
> >> EACCESS in reconnect_path()"
> >> is one suspect; it might be worth checking whether the problem's
> >> reproduceable with that reverted. But I assume we're not so lucky as to
> >> have a 100% reproduceable problem here?
> > Unknown. I've kicked off a fresh build. Here's hoping!
> I can trigger it reliably with a 2.6.26 client. I've also triggered it
> with 496d6c32d4d057cb44272d9bd587ff97d023ee92 reverted on the server.
> It's harder to trigger with 2.6.27-rc1+ but I managed to get an Oops
> on the fourth build after three successful builds on the NFS4 mount.
Not a regression from 2.6.26, apparently.
Following the rest of that thread (e.g. http://marc.info/?l=linux-nfsv4&m=121800494506042&w=4) it appears this was an ftrace bug?