From nobody Tue Jun 10 09:11:18 2025 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4bGjhg37SPz5tVRK; Tue, 10 Jun 2025 09:11:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4bGjhf6j2bz3GNy; Tue, 10 Jun 2025 09:11:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 55A9BIu7024063; Tue, 10 Jun 2025 12:11:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 55A9BIu7024063 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 55A9BIQK024062; Tue, 10 Jun 2025 12:11:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 10 Jun 2025 12:11:18 +0300 From: Konstantin Belousov To: Gleb Smirnoff Cc: Rick Macklem , Dag-Erling =?utf-8?B?U23DuHJncmF2?= , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 79d0f4474653 - main - rpcbind: Ensure krpc is present. Message-ID: References: <202506091053.559ArJ8k043104@gitrepo.freebsd.org> List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Rspamd-Queue-Id: 4bGjhf6j2bz3GNy X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Mon, Jun 09, 2025 at 08:02:02PM -0700, Gleb Smirnoff wrote: > On Tue, Jun 10, 2025 at 03:17:26AM +0300, Konstantin Belousov wrote: > K> > R> My vague recollection (I'll admit I cannot be bothered looking at the > K> > R> older code) > K> > R> is that rpcbind would accept queries on a AF_LOCAL (unix domain) socket for > K> > R> local RPC processes. > K> > R> > K> > R> glebius@ does not want RPCs to be done over AF_LOCAL sockets (he would > K> > R> have to explain why), so he created an RPC layer in the krpc for netlink as an > K> > R> alternative and converted all utilities that were doing RPCs over AF_LOCAL > K> > R> sockets to use it. > K> > > K> > Not exactly. I don't want kernel RPC to userland to use AF_LOCAL. A process to > K> > a process RPC of course continues to use AF_LOCAL. > K> > > K> > What would be better for rpcbind: to skip providing kernel RPC services if > K> > krpc(4) not detected at startup, or to autoload krpc? The latter makes it safe > K> > for a scenario when NFS is instantiated at a later runtime of a machine, when > K> > rpcbind already runs. The former scenario would require a restart of rpcbind. > K> > > K> > K> IMO rpcbind must not load any modules. It should communicate with krpc if > K> available. > K> > K> The krpc load is the global system policy decision, it should be handled > K> in rc scripts, as it is common for such decisions. The loading would be > K> enabled if some component requires krpc, which means if nfsd enabled. > K> It would be ordered before rpcbind startup, of course. > > My only concern is that it would require restart of rpcbind, if sysadmin > decides to configure NFS later after startup. Well, yes. Apparently we already have the feature called 'warmstart', where rpcbind can be restarted and existing registrations are reloaded. So it is in fact already solved, assuming admin is careful enough to use -w.