From: "J. Bruce Fields" <bfields@fieldses.org>
To: Sven Geggus <lists@fuchsschwanzdomain.de>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Kernel update 3.5.7 -> 3.6.3 breaks NFS4
Date: Mon, 29 Oct 2012 18:09:53 -0400 [thread overview]
Message-ID: <20121029220952.GA25655@fieldses.org> (raw)
In-Reply-To: <20121029163323.GA24345@geggus.net>
On Mon, Oct 29, 2012 at 05:33:23PM +0100, Sven Geggus wrote:
> J. Bruce Fields schrieb am Montag, den 29. Oktober um 16:02 Uhr:
>
> > Re-adding linux-nfs to cc
>
> OK
>
> > I don't understand why the server is dropping requests instead of
> > returning errors. I actually would have expected it to return BADVERF
> > to the DESTROY request and then accept the PUTROOTFH normally, which
> > might have allowed the mount to succeed despite the bizarre rpc.gssd
> > behavior.
>
> Hm rpc.gssd is the one from debian nfs-utils 1.2.6 looking at their custom
> patches inside the debian package there is nothing which could cause this.
>
> > I'd be curious to understand what changed on the server to make a
> > difference.
>
> Nothing but the kernel. I'm currently dual booting either 3.5.7 or 3.6.3
> vanilla kernels on the same system.
>
> > Looking at a network trace from a successful mount with 3.5.7 might be
> > useful.
>
> attached.
Thanks!
The sequence of events is pretty much what I described for the "bad"
trace, except that PUTROOTFH gets a succesful reply.
One other odd difference: in the "bad" case, the timing is a little
different: the socket gssd created doesn't get shut down in the same
way, and the PUTROOTFH comes more quickly on the heels of the FIN.
Which shouldn't make a difference.
Hm.
--b.
next prev parent reply other threads:[~2012-10-29 22:09 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-26 15:58 Kernel update 3.5.7 -> 3.6.3 breaks NFS4 Sven Geggus
2012-10-26 16:39 ` VDR User
2012-10-31 12:47 ` Sven Geggus
2012-10-26 17:15 ` J. Bruce Fields
[not found] ` <20121029094038.GA14836@geggus.net>
2012-10-29 15:02 ` J. Bruce Fields
2012-10-29 16:33 ` Sven Geggus
2012-10-29 22:09 ` J. Bruce Fields [this message]
2012-10-31 12:52 ` Sven Geggus
2012-10-31 14:28 ` VDR User
2012-10-31 15:33 ` Sven Geggus
2012-10-31 17:43 ` VDR User
2012-11-05 14:45 ` Sven Geggus
2012-11-05 16:55 ` Sven Geggus
2012-11-09 18:45 ` Sven Geggus
2012-11-09 20:07 ` J. Bruce Fields
2012-11-09 20:09 ` J. Bruce Fields
2012-11-09 22:45 ` Sven Geggus
2012-11-09 23:24 ` J. Bruce Fields
2012-11-12 9:17 ` Sven Geggus
2012-11-13 22:40 ` J. Bruce Fields
2012-11-14 0:58 ` J. Bruce Fields
2012-11-14 16:07 ` J. Bruce Fields
2012-11-14 16:08 ` J. Bruce Fields
2012-11-15 16:58 ` Sven Geggus
2012-11-16 19:19 ` J. Bruce Fields
2012-12-12 11:15 ` Sven Geggus
2012-12-12 18:57 ` J. Bruce Fields
2012-11-14 22:26 ` Eldad Zack
2012-11-09 23:17 ` Eldad Zack
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121029220952.GA25655@fieldses.org \
--to=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=lists@fuchsschwanzdomain.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.