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:   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. 
Thread-Topic: [PATCH v2 0/2] enhance NFSv4.2 SSC to delay unmount source's
 export. 
Thread-Index: AQHXKBgu9IXq70YdMUCq9qUqUB+L96qntQoAgAA0ZoCAAABtAIAAA/oAgAAAWACAAAyNgIAAS1AAgAAC94CAAP2GgIAAC9wAgAAeIICAABT2AIAAF5kAgAATgoCAACPHAIAA8l4A
Date:   Thu, 8 Apr 2021 15:25:53 +0000
Message-ID: <BB59428B-1B24-4FED-9465-F721EF99EFED@oracle.com>
References: <20210402233031.36731-1-dai.ngo@oracle.com>
 <D85FBDD3-5397-4D47-932D-159AFE2A5E0F@oracle.com>
 <CAN-5tyHVOEr7zZM92PVS0GYJQ2M6rSs6_zqZwuioumQQm7zzUQ@mail.gmail.com>
 <7BED2160-1052-49EE-BB62-6ACF6F84C91C@oracle.com>
 <CAN-5tyEKqNHmwiMfCpkZrCVYeaO-FH69v5L4Tk_8EsoTfytpVA@mail.gmail.com>
 <01CD778D-57A0-442A-8D1D-5084F0FC2497@oracle.com>
 <CAN-5tyFEXBiWVbCq0Hgh01W=OVZkdYYAEujSug6biBaU=Ny8Og@mail.gmail.com>
 <99a1f327-ce69-e6eb-39fc-77991bec5b4c@oracle.com>
 <c16b4437-a554-be60-3c04-fd578b9f88ff@oracle.com>
 <CAN-5tyGS0ZO4PtTseLSmC4=fYQCUwMs6FB509g2PSCg1v+jySg@mail.gmail.com>
 <0b0c7c79-d593-c4ae-db9b-46600f2cea28@oracle.com>
 <CAN-5tyGw8_xOfMM4PNUCvo_wKEHs5NgLo3ZQf-sTGb6FHJ_r8Q@mail.gmail.com>
 <3b6e1b4f-4276-e503-9432-e15a339cac9f@oracle.com>
 <CAN-5tyG7HPQxAK-o-q8=_-wtewBcymian2AQV__p=HgL+jJPcQ@mail.gmail.com>
 <d9a26bed-6e29-a0ea-b6a0-2fd30c240a9b@oracle.com>
 <CAN-5tyG4gQ4t0PF9v=8m4BfS-a3iRud0ywmLX2g-Vm8+FCosJA@mail.gmail.com>
In-Reply-To: <CAN-5tyG4gQ4t0PF9v=8m4BfS-a3iRud0ywmLX2g-Vm8+FCosJA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B869CAE86D91F149A013E8FB8C36FF92@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: aa373fd5-4eae-492b-baf1-08d8faa29947
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 15:25:53.5070
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ge6CzPbdeD2PLh0jJd6VYyHKd/OKyAkBXqewjaHtk+2M/TBfWsT1A/IU0tZfsSMBf77RrgJtlGsYfMkMp9Rrzg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB4768
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9948 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 bulkscore=0
 mlxlogscore=999 suspectscore=0 spamscore=0 phishscore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000
 definitions=main-2104080105
X-Proofpoint-GUID: 6tEMhmJwWTW3v1FgHlRMZ9TTEHZdsjrf
X-Proofpoint-ORIG-GUID: 6tEMhmJwWTW3v1FgHlRMZ9TTEHZdsjrf
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9948 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 clxscore=1015
 lowpriorityscore=0 suspectscore=0 adultscore=0 mlxlogscore=999 bulkscore=0
 priorityscore=1501 impostorscore=0 phishscore=0 mlxscore=0 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000
 definitions=main-2104080105
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Apr 7, 2021, at 8:58 PM, Olga Kornievskaia <olga.kornievskaia@gmail.co=
m> wrote:
>=20
> 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