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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35445C001B0 for ; Fri, 23 Jun 2023 13:10:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231528AbjFWNKf convert rfc822-to-8bit (ORCPT ); Fri, 23 Jun 2023 09:10:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231522AbjFWNKd (ORCPT ); Fri, 23 Jun 2023 09:10:33 -0400 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA0D92133 for ; Fri, 23 Jun 2023 06:10:30 -0700 (PDT) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with both STARTTLS and AUTH (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-308-LL79zkSiMMOLClOvKXuMbQ-1; Fri, 23 Jun 2023 14:10:27 +0100 X-MC-Unique: LL79zkSiMMOLClOvKXuMbQ-1 Received: from AcuMS.Aculab.com (10.202.163.4) by AcuMS.aculab.com (10.202.163.4) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Fri, 23 Jun 2023 14:10:26 +0100 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Fri, 23 Jun 2023 14:10:26 +0100 From: David Laight To: 'Matthew Wilcox' , stsp CC: Jeff Layton , "linux-kernel@vger.kernel.org" , Chuck Lever , Alexander Viro , Christian Brauner , "linux-fsdevel@vger.kernel.org" Subject: RE: [PATCH 2/3] fd/locks: allow get the lock owner by F_OFD_GETLK Thread-Topic: [PATCH 2/3] fd/locks: allow get the lock owner by F_OFD_GETLK Thread-Index: AQHZo32TC5N9nkgT8E+AvQ/6iJ//gK+YXybw Date: Fri, 23 Jun 2023 13:10:26 +0000 Message-ID: References: <20230620095507.2677463-1-stsp2@yandex.ru> <20230620095507.2677463-3-stsp2@yandex.ru> <5728ebda22a723b0eb209ae078e8f132d7b4ac7b.camel@kernel.org> <5f644a24-90b5-a02f-b593-49336e8e0f5a@yandex.ru> <2eb8566726e95a01536b61a3b8d0343379092b94.camel@kernel.org>

In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Matthew Wilcox > Sent: 20 June 2023 14:46 > > On Tue, Jun 20, 2023 at 06:39:07PM +0500, stsp wrote: > > Though it will, for sure, represent the > > task that _owns_ the lock. > > No, it *DOESN'T*. I can open a file, SCM_RIGHTS pass it to another task > and then exit. Now the only owner of that lock is the recipient ... > who may not even have received the fd yet. Do these locks persist across fork+exec? What happens is a completely unrelated process opens /proc//fd while a lock is held and then the (nominally) lock-holding process closes the fd (or exits). While it might be a useful diagnostic to know the pid of the process that acquired the lock it clearly has no relationship with any process that currently has an fd[] table entry that references the file. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)