History log of /freebsd/sys/rpc/clnt_vc.c (Results 1 – 25 of 103)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 56a96c51 01-Feb-2025 Gleb Smirnoff <glebius@FreeBSD.org>

rpcsec_tls/client: API refactoring between kernel and rpc.tlsclntd(8)

Now that the conversion of rpcsec_tls/client + rpc.tlsclntd(8) to the
netlink(4) socket as RPC transport started using kernel so

rpcsec_tls/client: API refactoring between kernel and rpc.tlsclntd(8)

Now that the conversion of rpcsec_tls/client + rpc.tlsclntd(8) to the
netlink(4) socket as RPC transport started using kernel socket pointer as
a reliable cookie, we can shave off quite a lot of complexity. We will
utilize the same kernel-generated cookie in all RPCs. And the need for
the daemon generated cookie in the form of timestamp+sequence vanishes.

In the clnt_vc.c we no longer need to store the userland cookie, but we
still need to observe the TLS life cycle of the client. We observe
RPCTLS_INHANDSHAKE state, that lives for a short time when the socket had
already been fetched by the daemon with the syscall, but the RPC call is
still waiting for the reply from daemon.

This time bump the RPC version.

Reviewed by: rmacklem
Differential Revision: https://reviews.freebsd.org/D48564

show more ...


# e3e36e1b 01-Feb-2025 Gleb Smirnoff <glebius@FreeBSD.org>

krpc: assert that we don't support kernel RPC over unix(4)

Reviewed by: rmacklem
Differential Revision: https://reviews.freebsd.org/D48563


Revision tags: release/14.1.0-p7, release/14.2.0-p1, release/13.4.0-p3
# 6a876e97 18-Jan-2025 Gleb Smirnoff <glebius@FreeBSD.org>

krpc/clnt_vc: clear vnet context before kthread_exit()

Fixes: b2ff4cb1931c2e1509a5741f6743322699ad1e00


# b2ff4cb1 17-Jan-2025 Gleb Smirnoff <glebius@FreeBSD.org>

krpc/clnt_vc: set vnet(9) context in clnt_vc kthread

The per-client kthread to offload TLS stuff was added ab0c29af0512d. Let
it run in the vnet(9) that matches associated socket.


# d9f9a73a 17-Jan-2025 Gleb Smirnoff <glebius@FreeBSD.org>

krpc/clnt_vc: in clnt_vc_destroy() use more lapidary logic

on whether to close the socket or leave it.


# 9d04973b 17-Jan-2025 Gleb Smirnoff <glebius@FreeBSD.org>

krpc/clnt_vc: remove always false check

We just initialized ct_closeit to false a few lines above.


Revision tags: release/14.2.0, release/13.4.0, release/14.1.0
# 4ba444de 27-Apr-2024 Rick Macklem <rmacklem@FreeBSD.org>

krpc: Ref cnt the client structures for TLS upcalls

A crash occurred during testing, where the client structures had
already been free'd when the upcall thread tried to lock them.

This patch acquir

krpc: Ref cnt the client structures for TLS upcalls

A crash occurred during testing, where the client structures had
already been free'd when the upcall thread tried to lock them.

This patch acquires a reference count on both of the structures
and these are released when the upcall is done, so that the
structures cannot be free'd prematurely. This happened because
the testing is done over a very slow vpn.

Found during a IETF bakeathon testing event this week.

MFC after: 5 days

show more ...


# e205fd31 09-Apr-2024 Gleb Smirnoff <glebius@FreeBSD.org>

rpc: use new macros to lock socket buffers

Fixes: d80a97def9a1db6f07f5d2e68f7ad62b27918947


Revision tags: release/13.3.0
# f79a8585 30-Jan-2024 Gleb Smirnoff <glebius@FreeBSD.org>

sockets: garbage collect SS_ISCONFIRMING

Fixes: 8df32b19dee92b5eaa4b488ae78dca6accfcb38e


# 29363fb4 23-Nov-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl s

sys: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl script.

Sponsored by: Netflix

show more ...


Revision tags: release/14.0.0
# 685dc743 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


Revision tags: release/13.2.0, release/12.4.0
# 82512c17 15-Oct-2022 Rick Macklem <rmacklem@FreeBSD.org>

clnt_vc.c: Replace msleep() with pause() to avoid assert panic

An msleep() in clnt_vc.c used a global "fake_wchan" wchan argument
along with the mutex in a CLIENT structure. As such, it was
possibl

clnt_vc.c: Replace msleep() with pause() to avoid assert panic

An msleep() in clnt_vc.c used a global "fake_wchan" wchan argument
along with the mutex in a CLIENT structure. As such, it was
possible to use different mutexes for the same wchan and
cause a panic assert. Since this is in a rarely executed code
path, the assert panic was only recently observed.

Since "fake_wchan" never gets a wakeup, this msleep() can
be replaced with a pause() to avoid the panic assert,
which is what this patch does.

Reviewed by: kib, markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D36977

show more ...


# 0b4f2ab0 15-May-2022 Rick Macklem <rmacklem@FreeBSD.org>

krpc: Fix NFS-over-TLS for KTLS1.3

When NFS-over-TLS uses KTLS1.3, the client can receive
post-handshake handshake records. These records can be
safely thown away, but are not handled correctly via

krpc: Fix NFS-over-TLS for KTLS1.3

When NFS-over-TLS uses KTLS1.3, the client can receive
post-handshake handshake records. These records can be
safely thown away, but are not handled correctly via the
rpctls_ct_handlerecord() upcall to the daemon.

Commit 373511338d95 changed soreceive_generic() so that it
will only return ENXIO for Alert records when MSG_TLSAPPDATA
is specified. As such, the post-handshake handshake
records will be returned to the krpc.

This patch modifies the krpc so that it will throw
these records away, which seems sufficient to make
NFS-over-TLS work with KTLS1.3. This change has
no effect on the use of KTLS1.2, since it does not
generate post-handshake handshake records.

MFC after: 2 weeks

show more ...


# 43283184 12-May-2022 Gleb Smirnoff <glebius@FreeBSD.org>

sockets: use socket buffer mutexes in struct socket directly

Since c67f3b8b78e the sockbuf mutexes belong to the containing socket,
and socket buffers just point to it. In 74a68313b50 macros that a

sockets: use socket buffer mutexes in struct socket directly

Since c67f3b8b78e the sockbuf mutexes belong to the containing socket,
and socket buffers just point to it. In 74a68313b50 macros that access
this mutex directly were added. Go over the core socket code and
eliminate code that reaches the mutex by dereferencing the sockbuf
compatibility pointer.

This change requires a KPI change, as some functions were given the
sockbuf pointer only without any hint if it is a receive or send buffer.

This change doesn't cover the whole kernel, many protocols still use
compatibility pointers internally. However, it allows operation of a
protocol that doesn't use them.

Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D35152

show more ...


Revision tags: release/13.1.0
# 77bc5890 05-Apr-2022 Warner Losh <imp@FreeBSD.org>

clnt_vc_destroy: eliminiate write only variable stat

Sponsored by: Netflix


Revision tags: release/12.3.0
# e3ba94d4 09-Nov-2021 John Baldwin <jhb@FreeBSD.org>

Don't require the socket lock for sorele().

Previously, sorele() always required the socket lock and dropped the
lock if the released reference was not the last reference. Many
callers locked the s

Don't require the socket lock for sorele().

Previously, sorele() always required the socket lock and dropped the
lock if the released reference was not the last reference. Many
callers locked the socket lock just before calling sorele() resulting
in a wasted lock/unlock when not dropping the last reference.

Move the previous implementation of sorele() into a new
sorele_locked() function and use it instead of sorele() for various
places in uipc_socket.c that called sorele() while already holding the
socket lock.

The sorele() macro now uses refcount_release_if_not_last() try to drop
the socket reference without locking the socket. If that shortcut
fails, it locks the socket and calls sorele_locked().

Reviewed by: kib, markj
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D32741

show more ...


# 20d728b5 09-Jul-2021 Mark Johnston <markj@FreeBSD.org>

rpc: Make function tables const

No functional change intended.

MFC after: 1 week
Sponsored by: The FreeBSD Foundation


Revision tags: release/13.0.0, release/12.2.0
# e2515283 27-Aug-2020 Glen Barber <gjb@FreeBSD.org>

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)


# ab0c29af 22-Aug-2020 Rick Macklem <rmacklem@FreeBSD.org>

Add TLS support to the kernel RPC.

An internet draft titled "Towards Remote Procedure Call Encryption By Default"
describes how TLS is to be used for Sun RPC, with NFS as an intended use case.
This

Add TLS support to the kernel RPC.

An internet draft titled "Towards Remote Procedure Call Encryption By Default"
describes how TLS is to be used for Sun RPC, with NFS as an intended use case.
This patch adds client and server support for this to the kernel RPC,
using KERN_TLS and upcalls to daemons for the handshake, peer reset and
other non-application data record cases.

The upcalls to the daemons use three fields to uniquely identify the
TCP connection. They are the time.tv_sec, time.tv_usec of the connection
establshment, plus a 64bit sequence number. The time fields avoid problems
with re-use of the sequence number after a daemon restart.
For the server side, once a Null RPC with AUTH_TLS is received, kernel
reception on the socket is blocked and an upcall to the rpctlssd(8) daemon
is done to perform the TLS handshake. Upon completion, the completion
status of the handshake is stored in xp_tls as flag bits and the reply to
the Null RPC is sent.
For the client, if CLSET_TLS has been set, a new TCP connection will
send the Null RPC with AUTH_TLS to initiate the handshake. The client
kernel RPC code will then block kernel I/O on the socket and do an upcall
to the rpctlscd(8) daemon to perform the handshake.
If the upcall is successful, ct_rcvstate will be maintained to indicate
if/when an upcall is being done.

If non-application data records are received, the code does an upcall to
the appropriate daemon, which will do a SSL_read() of 0 length to handle
the record(s).

When the socket is being shut down, upcalls are done to the daemons, so
that they can perform SSL_shutdown() calls to perform the "peer reset".

The rpctlssd(8) and rpctlscd(8) daemons require a patched version of the
openssl library and, as such, will not be committed to head at this time.

Although the changes done by this patch are fairly numerous, there should
be no semantics change to the kernel RPC at this time.
A future commit to the NFS code will optionally enable use of TLS for NFS.

show more ...


# b94b9a80 21-Jun-2020 Rick Macklem <rmacklem@FreeBSD.org>

Fix up a comment added by r362455.


# 4302e8b6 21-Jun-2020 Rick Macklem <rmacklem@FreeBSD.org>

Modify the way the client side krpc does soreceive() for TCP.

Without this patch, clnt_vc_soupcall() first does a soreceive() for
4 bytes (the Sun RPC over TCP record mark) and then soreceive(s) for

Modify the way the client side krpc does soreceive() for TCP.

Without this patch, clnt_vc_soupcall() first does a soreceive() for
4 bytes (the Sun RPC over TCP record mark) and then soreceive(s) for
the RPC message.
This first soreceive() almost always results in an mbuf allocation,
since having the 4byte record mark in a separate mbuf in the socket
rcv queue is unlikely.
This is somewhat inefficient and rather odd. It also will not work
for the ktls rx, since the latter returns a TLS record for each
soreceive().

This patch replaces the above with code similar to what the server side
of the krpc does for TCP, where it does a soreceive() for as much data
as possible and then parses RPC messages out of the received data.
A new field of the TCP socket structure called ct_raw is the list of
received mbufs that the RPC message(s) are parsed from.
I think this results in cleaner code and is needed for support of
nfs-over-tls.
It also fixes the code for the case where a server sends an RPC message
in multiple RPC message fragments. Although this is allowed by RFC5531,
no extant NFS server does this. However, it is probably good to fix this
in case some future NFS server does do this.

show more ...


Revision tags: release/11.4.0, release/12.1.0, release/11.3.0, release/12.0.0, release/11.2.0
# 82725ba9 23-Nov-2017 Hans Petter Selasky <hselasky@FreeBSD.org>

Merge ^/head r325999 through r326131.


# 51369649 20-Nov-2017 Pedro F. Giffuni <pfg@FreeBSD.org>

sys: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 3-Clause license.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for

sys: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 3-Clause license.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.

show more ...


Revision tags: release/10.4.0, release/11.1.0
# 7e1b7636 08-May-2017 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r317808 through r317970.


# dfd174d6 07-May-2017 Rick Macklem <rmacklem@FreeBSD.org>

Fix the client side krpc from doing TCP reconnects for ERESTART from sosend().

When sosend() replies ERESTART in the client side krpc, it indicates that
the RPC message hasn't yet been sent and that

Fix the client side krpc from doing TCP reconnects for ERESTART from sosend().

When sosend() replies ERESTART in the client side krpc, it indicates that
the RPC message hasn't yet been sent and that the send queue is full or
locked while a signal is posted for the process.
Without this patch, this would result in a RPC_CANTSEND reply from
clnt_vc_call(), which would cause clnt_reconnect_call() to create a new
TCP transport connection. For most NFS servers, this wasn't a serious problem,
although it did imply retries of outstanding RPCs, which could possibly
have missed the DRC.
For an NFSv4.1 mount to AmazonEFS, this caused a serious problem, since
AmazonEFS often didn't retain the NFSv4.1 session and would reply with
NFS4ERR_BAD_SESSION. This implies to the client a crash/reboot which
requires open/lock state recovery.

Three options were considered to fix this:
- Return the ERESTART all the way up to the system call boundary and then
have the system call redone. This is fraught with risk, due to convoluted
code paths, asynchronous I/O RPCs etc. cperciva@ worked on this, but it
is still a work in prgress and may not be feasible.
- Set SB_NOINTR for the socket buffer. This fixes the problem, but makes
the sosend() completely non interruptible, which kib@ considered
inappropriate. It also would break forced dismount when a thread
was blocked in sosend().
- Modify the retry loop in clnt_vc_call(), so that it loops for this case
for up to 15sec. Testing showed that the sosend() usually succeeded by
the 2nd retry. The extreme case observed was 111 loop iterations, or
about 100msec of delay.
This third alternative is what is implemented in this patch, since the
change is:
- localized
- straightforward
- forced dismount is not broken by it.

This patch has been tested by cperciva@ extensively against AmazonEFS.

Reported by: cperciva
Tested by: cperciva
MFC after: 2 weeks

show more ...


12345