Page MenuHomeFreeBSD

kgssapi: use netlink RPC client to talk to gssd(8)
ClosedPublic

Authored by glebius on Jan 20 2025, 9:03 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Apr 26, 9:23 AM
Unknown Object (File)
Sun, Apr 6, 1:23 PM
Unknown Object (File)
Mar 10 2025, 5:39 AM
Unknown Object (File)
Mar 8 2025, 7:40 AM
Unknown Object (File)
Feb 3 2025, 2:59 AM
Unknown Object (File)
Feb 2 2025, 11:53 PM
Unknown Object (File)
Feb 2 2025, 5:16 PM
Unknown Object (File)
Feb 2 2025, 12:25 AM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 61879
Build 58763: arc lint + arc unit

Event Timeline

brooks added inline comments.
sys/kgssapi/gss_impl.c
92

I'm unsure about the exact sequence of events expected with respect to starting this timeout and starting the daemon, but 1 minute isn't super long under emulation so I'm not sure if reducing from 5 to 1 minute is likely to be a problem.

sys/kgssapi/gss_impl.c
92

I decided to change the timeout parameters together with the transport. With the unix/stream socket I really don't see much value in retries at all: if the daemon is absent, we would get error; if the daemon has hang, retries doesn't make sense - unix/stream is reliable, the data is waiting in the socket for the daemon.

5 minutes sounds like overkill to me. If you want I can get it back to 5 minutes, but I will do also increase retries then. So that client keeps sending the RPC call constantly. If the daemon is restarted, doesn't make sense to wait a minute.

P.S. Thanks a lot for looking at the patches!

  • Put back the original overall timeout of 5 minutes. Let's not mix this with change of transport.
  • However, put much more retries into this timeout. The nature of the clnt_nl is different to clnt_reconnect + clnt_vc, and we should retry much more often.
This revision is now accepted and ready to land.Jan 29 2025, 10:16 PM