From: Chuck Lever III <chuck.lever@oracle.com>
To: Olga Kornievskaia <olga.kornievskaia@gmail.com>,
Dai Ngo <dai.ngo@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Trond Myklebust <trondmy@hammerspace.com>,
Bruce Fields <bfields@fieldses.org>
Subject: Re: [PATCH v2 0/2] enhance NFSv4.2 SSC to delay unmount source's export.
Date: Thu, 8 Apr 2021 15:25:53 +0000 [thread overview]
Message-ID: <BB59428B-1B24-4FED-9465-F721EF99EFED@oracle.com> (raw)
In-Reply-To: <CAN-5tyG4gQ4t0PF9v=8m4BfS-a3iRud0ywmLX2g-Vm8+FCosJA@mail.gmail.com>
> On Apr 7, 2021, at 8:58 PM, Olga Kornievskaia <olga.kornievskaia@gmail.com> wrote:
>
> Furthermore, I still really would like Bruce or Chuck to weigh in on
> the use of the semaphore.
The semaphore caught my eye too.
The usual trick to prevent a mount from disappearing is to
bump a reference count until it is safe for the mount to
possibly go away. Dai, if you can make this work with just
an extra reference count, I would prefer that.
> We are holding onto a semaphore while doing
> vfs_kern_mount(), I thought it's frowned upon to hold any locks while
> doing network operations. What if vfs_kern_mount() is trying to reach
> an unresponsive server, then all other unmount are blocked, right? I
> still don't understand why we need a semaphore. I think a spin lock
> that protects access to the list of umounts is sufficient. I probably
> should be commenting on the actual patch here.
--
Chuck Lever
next prev parent reply other threads:[~2021-04-08 15:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-02 23:30 [PATCH v2 0/2] enhance NFSv4.2 SSC to delay unmount source's export Dai Ngo
2021-04-02 23:30 ` [PATCH v2 1/2] NFSD: delay unmount source's export after inter-server copy completed Dai Ngo
2021-04-02 23:30 ` [PATCH v2 2/2] NFSv4.2: mount overhead should not be used as threshold for inter-server copy Dai Ngo
2021-04-06 16:33 ` [PATCH v2 0/2] enhance NFSv4.2 SSC to delay unmount source's export Chuck Lever III
2021-04-06 19:41 ` Olga Kornievskaia
2021-04-06 19:42 ` Chuck Lever III
2021-04-06 19:57 ` Olga Kornievskaia
2021-04-06 19:58 ` Chuck Lever III
2021-04-06 20:43 ` Olga Kornievskaia
2021-04-07 1:12 ` dai.ngo
2021-04-07 1:23 ` dai.ngo
[not found] ` <CAN-5tyGS0ZO4PtTseLSmC4=fYQCUwMs6FB509g2PSCg1v+jySg@mail.gmail.com>
2021-04-07 17:13 ` dai.ngo
2021-04-07 19:01 ` Olga Kornievskaia
2021-04-07 20:16 ` dai.ngo
2021-04-07 21:40 ` Olga Kornievskaia
2021-04-07 22:50 ` dai.ngo
2021-04-08 0:58 ` Olga Kornievskaia
2021-04-08 7:19 ` dai.ngo
2021-04-08 15:25 ` Chuck Lever III [this message]
2021-04-06 19:58 ` dai.ngo
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=BB59428B-1B24-4FED-9465-F721EF99EFED@oracle.com \
--to=chuck.lever@oracle.com \
--cc=bfields@fieldses.org \
--cc=dai.ngo@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=olga.kornievskaia@gmail.com \
--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.