Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     "J. Bruce Fields" <bfields@fieldses.org>
Cc:     chuck.lever@oracle.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH] NFSD: Keep existing listners on portlist error
Date:   Wed, 06 Oct 2021 10:43:14 -0400
Message-ID: <053E93B5-0DFB-4A20-9742-F3894E2BE224@redhat.com>
In-Reply-To: <20211006143335.GA15343@fieldses.org>
References: <45b916f1aa3fb7c059a574f61188a8f2f615410e.1633529847.git.bcodding@redhat.com>
 <20211006143335.GA15343@fieldses.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Precedence: bulk

On 6 Oct 2021, at 10:33, J. Bruce Fields wrote:

> On Wed, Oct 06, 2021 at 10:18:05AM -0400, Benjamin Coddington wrote:
>> If nfsd has existing listening sockets without any processes, then an 
>> error
>> returned from svc_create_xprt() for an additional transport will 
>> remove
>> those existing listeners.  We're seeing this in practice when 
>> userspace
>> attempts to create rpcrdma transports without having the rpcrdma 
>> modules
>> present before creating nfsd kernel processes.  Fix this by checking 
>> for
>> existing sockets before callingn nfsd_destroy().
>
> That seems like an improvement.
>
> I'm curious, though, what the rpc.nfsd behavior is on partial failure.
> And what do we want it to be?
>
> If a user runs rpc.nfsd expecting it to start up tcp and rdma, but 
> rdma
> fails, do we want rpc.nfsd to succeed or fail?  Should it exit with 
> nfsd
> running or not?

I lean toward having it fail - but I think that's a different patch for
rpc.nfsd.  Right now rpc.nfsd exists without error, but you end up 
without
any listeners at all.

Do you want a patch for rpc.nfsd instead?

Ben