From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AAD54C3A5A3 for ; Tue, 27 Aug 2019 20:51:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8681C20656 for ; Tue, 27 Aug 2019 20:51:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728371AbfH0Uv6 (ORCPT ); Tue, 27 Aug 2019 16:51:58 -0400 Received: from fieldses.org ([173.255.197.46]:48176 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726584AbfH0Uv6 (ORCPT ); Tue, 27 Aug 2019 16:51:58 -0400 Received: by fieldses.org (Postfix, from userid 2815) id 60EA01C84; Tue, 27 Aug 2019 16:51:58 -0400 (EDT) Date: Tue, 27 Aug 2019 16:51:58 -0400 From: "J. Bruce Fields" To: Alex Lyakas Cc: chuck.lever@oracle.com, linux-nfs@vger.kernel.org, Shyam Kaushik Subject: Re: [RFC-PATCH] nfsd: when unhashing openowners, increment openowner's refcount Message-ID: <20190827205158.GB13198@fieldses.org> References: <1566406146-7887-1-git-send-email-alex@zadara.com> <20190826133951.GC22759@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Tue, Aug 27, 2019 at 12:05:28PM +0300, Alex Lyakas wrote: > Is the described issue familiar to you? Yep, got it, but I haven't seen anyone try to solve it using the fault injection code, that's interesting! There's also fs/nfsd/unlock_filesystem. It only unlocks NLM (NFSv3) locks. But it'd probably be reasonable to teach it to get NFSv4 state too (locks, opens, delegations, and layouts). But my feeling's always been that the cleanest way to do it is to create two containers with separate net namespaces and run nfsd in both of them. You can start and stop the servers in the different containers independently. > It is very easily reproducible. What is the way to solve it? To our > understanding, if we un-export a FS from nfsd, we should be able to > unmount it. Unexporting has never removed locks or opens or other state, for what it's worth. --b.