Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <9f79ef7f-81c3-9e63-0ac7-467fc851f1f8@arrikto.com>
Date:   Wed, 18 Jan 2023 16:05:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: [PATCH] nfsd: Ensure knfsd shuts down when the "nfsd" pseudofs is
 unmounted
To:     Chuck Lever III <chuck.lever@oracle.com>
Cc:     "trondmy@kernel.org" <trondmy@kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
References: <20210313210847.569041-1-trondmy@kernel.org>
 <936effe2-1268-42ab-886e-649b7c501828@arrikto.com>
 <DCF5C3D1-E4D0-4F40-81AA-38B74276B858@oracle.com>
Content-Language: en-US
From:   Nikos Tsironis <ntsironis@arrikto.com>
In-Reply-To: <DCF5C3D1-E4D0-4F40-81AA-38B74276B858@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 12/22/22 16:48, Chuck Lever III wrote:
> [ Cc: Bruce removed because that address no longer works ]
> 
>> On Dec 20, 2022, at 8:43 AM, Nikos Tsironis <ntsironis@arrikto.com> wrote:
>>
>> On 3/13/21 23:08, trondmy@kernel.org wrote:
>>> From: Trond Myklebust <trond.myklebust@hammerspace.com>
>>> In order to ensure that knfsd threads don't linger once the nfsd
>>> pseudofs is unmounted (e.g. when the container is killed) we let
>>> nfsd_umount() shut down those threads and wait for them to exit.
>>> This also should ensure that we don't need to do a kernel mount of
>>> the pseudofs, since the thread lifetime is now limited by the
>>> lifetime of the filesystem.
>>> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
>>> ---
>>
>> Hello,
>>
>> This patch was merged in kernel v5.13, but the issue exists in older
>> kernels too.
>>
>> Is there a reason that the patch was never backported to older stable
>> kernels?
> 
> Hello Nikos-
> 
> A probable reason is there is no Fixes: or Cc: stable@vger tag in the
> merged commit, so it will not be cherry-picked by AUTOSEL. Another
> reason might be that the patch does not apply cleanly to LTS kernels.
> 
> You can make a request to stable@ for this patch to be backported, but
> I would prefer if you apply the patch and test it on each target kernel
> before making such a request. Or, you can pick which LTS kernel(s) are
> most relevant to you and ask for backport to only those.
> 
> A good test will have three parts:
> 
> - Make a positive confirmation the issue exists in that kernel
> 
> - Make sure the patch applies cleanly verbatim and causes no regression
> 
> - Make sure the patch fixes the issue in that kernel
> 
> It's a bit of (albeit mechanical) effort, and the Linux NFS community
> doesn't have the resources to manage it for all patches going into
> mainline to six different LTS kernels.
> 

Hello Chuck,

Thanks for the feedback, and sorry for the late reply.

I will backport the patch myself to LTS kernels 5.4 and 5.10, test it,
and send it to stable@ to request inclusion in these two kernels.

Nikos