Subject : nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1 Submitter : Paul Collins <paul@burly.ondioline.org> 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" <bfields@fieldses.org>
On Sunday, 3 of August 2008, Paul Collins wrote: > Paul Collins <paul@burly.ondioline.org> writes: > > > "J. Bruce Fields" <bfields@fieldses.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 > >>> 2.18.50.20080610-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?