| 2008-05-30 15:27:09 |
Andrew Pollock |
description |
The daemon rpc.gssd uses the clnttcp_create function from librpcsecgss.so to build authentication connections NFS servers providing Kerberized NFS. If a connect() call is taking a long time, then there is a good chance that a change to the pipefs will cause rpc.gssd to get a signal.
We've provided a patch to upstream, which they've accepted. 0.18 contains the fix. I'll also add the patch here, and look at providing a debdiff that incorporates the patch, if I can wrap my head around CDBS. |
The daemon rpc.gssd uses the clnttcp_create function from librpcsecgss.so to build authentication connections NFS servers providing Kerberized NFS. If a connect() call is taking a long time, then there is a good chance that a change to the pipefs will cause rpc.gssd to get a signal.
We've provided a patch to upstream, which they've accepted. 0.18 contains the fix. I'll also add the patch here, and look at providing a debdiff that incorporates the patch, if I can wrap my head around CDBS.
This bug impacts users of systems that utilise Kerberised NFS in an environment with automounting. On sufficiently loaded systems, the signal from a new mount may interrupt a connect() in progress for an existing mount being made. This can render NFS in such environments ineffective.
A patch has been provided upstream, which they have incorporated into the released 0.18 version of the software. 0.18-1 is in Debian, and A sync has been requested in #234297
A patch and debdiff are attached to this bug report.
TEST CASE:
Probably a difficult one, you'd need a Kerberised NFS environment to start with, then you'd have put the client mounting shares under load, and make subsequent mount attempts. I think it's fairly non-deterministic, but I'm not the original internal bug submitter, so I don't have first-hand details.
|
|
