All of lore.kernel.org
 help / color / mirror / Atom feed
From: Charles Hedrick <hedrick@rutgers.edu>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	"trondmy@hammerspace.com" <trondmy@hammerspace.com>,
	Bruce Fields <bfields@fieldses.org>,
	Jeff Layton <jlayton@redhat.com>, Dai Ngo <dai.ngo@oracle.com>
Subject: Re: [PATCH RFC 0/2] Fix "sleep while locked" in RELEASE_LOCKOWNER
Date: Fri, 27 May 2022 00:21:23 +0000	[thread overview]
Message-ID: <24401119-4BFD-4A27-BFE7-15FD92DA8FF6@rutgers.edu> (raw)
In-Reply-To: <0387546F-0850-4BD3-B2DB-FCBEE1242610@oracle.com>

I was hoping it was reasonable to ask for backporting to the latest LTS. It would be nice if you could make the statement you did about that. At that point I agree that it’s Ubuntu’s problem.

> On May 26, 2022, at 7:39 PM, Chuck Lever III <chuck.lever@oracle.com> wrote:
> 
> 
> 
>> On May 26, 2022, at 3:17 PM, Charles Hedrick <hedrick@rutgers.edu> wrote:
>> 
>> We are still stuck on NFS 3 because NFS 4 lock operations hang. Typically with thunderbird, firefox, etc. I had hoped that Ubuntu 22 would fix this, given the patch 
>> 
>> UNRPC: Don't call connect() more than once on a TCP socket
>> 
>> If this is part of the problem, that would mean we couldn't use NFS 4 until Ubuntu 24, i.e. summer of 2025, given delays in release and deployment.
>> 
>> Unfortunately I can't reproduce our problem. It doesn't show up until we're halfway into our semester and loads start getting heavier.
>> 
>> You say this is a long-standing issue. So are problems with NFS 4 locking (and also NFS 4 delegation). If you have a patch for both of these issues that we could put into 5.4.0, I might be willing to test it, assuming the patches are safe. We probably wouldn't know it has really fixed things for at least 6 months.
> 
> Charles, this mailing list is an upstream Linux forum. There honestly isn't anything we can do about Ubuntu backporting policies, and we can't help much at all with Linux kernels as old as v5.4 unless there are known fixes in later kernels. It's up to you to find those fixes, test them, and then convince the stable kernel folks and your distribution to include the fix in their kernel. The folks on linux-nfs@ are little more than process observers in those communities.
> 
> The RELEASE_LOCKOWNER lock inversion issue has been around forever, but it was exposed recently by a performance regression fix in v5.18-rc3. After that point, a client can leverage the existing lock inversion bug to provoke a deadlock on the server using normal NFSv4 operations. That makes the RELEASE_LOCKOWNER issue a potential denial-of-service in the latest kernels, which is priority one in my book.
> 
> I stand by my statement to Linus in this morning's pull request: I currently know of no other high priority bugs in v5.18's NFS server (I'm not talking about the NFS client) under active investigation except for the one I mentioned in the PR. If you know of /specific/ reports of significant incorrect behavior in the latest upstream Linux NFS client or server, please post links to them here, or better yet, file bugs and help the assignees to troubleshoot the problems.
> 
> 
> --
> Chuck Lever
> 
> 
> 

  reply	other threads:[~2022-05-27  0:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-11 21:52 [PATCH RFC 0/2] Fix "sleep while locked" in RELEASE_LOCKOWNER Chuck Lever
2022-05-11 21:52 ` [PATCH RFC 1/2] NFSD: nfsd4_release_lockowner() should drop clp->cl_lock sooner Chuck Lever
2022-05-11 22:04   ` Trond Myklebust
2022-05-12 14:03     ` Chuck Lever III
2022-05-12 10:07   ` Jeff Layton
2022-05-12 14:10     ` Chuck Lever III
2022-05-11 21:52 ` [PATCH RFC 2/2] NFSD: nfsd_file_put() can sleep Chuck Lever
2022-05-12 10:08   ` Jeff Layton
     [not found] ` <PH0PR14MB549335582C7A4D4F4D2269B2AAD99@PH0PR14MB5493.namprd14.prod.outlook.com>
2022-05-26 23:39   ` [PATCH RFC 0/2] Fix "sleep while locked" in RELEASE_LOCKOWNER Chuck Lever III
2022-05-27  0:21     ` Charles Hedrick [this message]
2022-05-27 15:32       ` Chuck Lever III

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=24401119-4BFD-4A27-BFE7-15FD92DA8FF6@rutgers.edu \
    --to=hedrick@rutgers.edu \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=dai.ngo@oracle.com \
    --cc=jlayton@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@hammerspace.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.