From: Doug Nazar <nazard@nazar.ca>
To: "Kraus, Sebastian" <sebastian.kraus@tu-berlin.de>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v2] Re: Strange segmentation violations of rpc.gssd in Debian Buster
Date: Wed, 1 Jul 2020 14:45:56 -0400 [thread overview]
Message-ID: <55d6fafa-222c-1d55-d1ec-0bb6d7ab9350@nazar.ca> (raw)
In-Reply-To: <94422f073b7e4b979931e6d8d3a0c044@tu-berlin.de>
On 2020-07-01 03:39, Kraus, Sebastian wrote:
> OK, thanks for the info. I wondered, because your patch did not show
> up as a commit within upstream.
> Your patch seems to do a good job - no more segfaults since a period of four days. :-)
I'm not a maintainer, just an enthusiastic user with a compiler... ;-)
I'm sure it'll get applied in the near future, as time permits.
>> I've found one other place that has insufficient locking but the race to hit it is fairly small. It's in the Kerberos machine principal cache when it refreshes the machine credentials.
> These type of patches are always welcome. :-)
> In the recent past, some of our scientific staff exprienced strange problems with Kerberos authentication against our NFSv4 file servers.
> Maybe, the outages were in connection with this type of race condition. But, I do not know for sure as the authentication errors did happen on a rather sporadic basis.
The previous bug could also cause authentication issues without crashing
depending on load, timing, memory usage, malloc library, etc. This one
would only crop up during machine credentials refresh, which by default
is once every 24 hours. I've just posted a patch 'gssd: Fix locking for
machine principal list', the interesting part for backporting is around
line 447. It used to always strdup() even if cache name was the same.
>> I have a patch for that, but it's pretty invasive due to some other changes I'm currently working on. Let me know if you hit it, and I can work on a simple version to backport.
> NFSv4+Kerberos is not for the faint-hearted. I do not fear of invasive patches - as long as they are not missing technical correctness. ;-)
No guarantees... but I do try. ;-)
> A question far apart from this:
> How is it about the spread of NFSv4+Kerberos setups within academic community and commerical environments?
> Are there, up to your knowledge, any bigger on-premise or cloud setups out there?
> And are there any companies running dedicated NFSv4+Kerberos setups?
I really have no idea. I only run it on my home network of a few dozen
(old) machines. From what I've seen while googling
trying to figure out how the code base works, there are fair number of
users. There's also been a large amount of work in
recent years, which would point to something driving that.
Doug
prev parent reply other threads:[~2020-07-01 18:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-19 21:24 RPC Pipefs: Frequent parsing errors in client database Kraus, Sebastian
2020-06-19 22:04 ` J. Bruce Fields
2020-06-20 11:35 ` Kraus, Sebastian
2020-06-20 17:03 ` J. Bruce Fields
2020-06-20 21:08 ` Kraus, Sebastian
2020-06-22 22:36 ` J. Bruce Fields
2020-06-25 17:43 ` Strange segmentation violations of rpc.gssd in Debian Buster Kraus, Sebastian
2020-06-25 20:14 ` J. Bruce Fields
2020-06-25 21:44 ` Doug Nazar
2020-06-26 12:31 ` Kraus, Sebastian
2020-06-26 17:23 ` Doug Nazar
2020-06-26 19:46 ` J. Bruce Fields
2020-06-26 20:15 ` Doug Nazar
2020-06-26 21:02 ` J. Bruce Fields
2020-06-26 21:30 ` [PATCH v2] " Doug Nazar
2020-06-26 21:44 ` J. Bruce Fields
2020-06-29 5:39 ` Kraus, Sebastian
2020-06-29 14:09 ` Doug Nazar
2020-07-01 7:39 ` Kraus, Sebastian
2020-07-01 8:13 ` [PATCH v2] " Peter Eriksson
2020-07-01 18:45 ` Doug Nazar [this message]
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=55d6fafa-222c-1d55-d1ec-0bb6d7ab9350@nazar.ca \
--to=nazard@nazar.ca \
--cc=linux-nfs@vger.kernel.org \
--cc=sebastian.kraus@tu-berlin.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).