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 B74EEEB64DD for ; Tue, 27 Jun 2023 16:21:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230488AbjF0QVa (ORCPT ); Tue, 27 Jun 2023 12:21:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231725AbjF0QVL (ORCPT ); Tue, 27 Jun 2023 12:21:11 -0400 Received: from forward501b.mail.yandex.net (forward501b.mail.yandex.net [IPv6:2a02:6b8:c02:900:1:45:d181:d501]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BEB9E30D6; Tue, 27 Jun 2023 09:20:42 -0700 (PDT) Received: from mail-nwsmtp-smtp-production-main-18.iva.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-18.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:5e29:0:640:6b8b:0]) by forward501b.mail.yandex.net (Yandex) with ESMTP id 7A4E75EDC6; Tue, 27 Jun 2023 19:20:36 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-18.iva.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id WKOEHL1WsiE0-MlTFllBQ; Tue, 27 Jun 2023 19:20:35 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1687882835; bh=oWCGWtFnCjNqqD1WMRbx7b1uArOcxMJZ0ZCi5PjthmM=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=Pchl2J5ejPI6wKGbXgDartG31TfSQMycg3aSNeNM2Bm7Df87pZj6SEi+eZOMWzf6E Kr0RLEjiF+U2jeV1za7Sjj2TgPeRQaSkA7V0+HTK0rdlUqLUHlRdtmnjFo9nNELV1u 2FxnwE5p/ew7rDbsI/gCDHgJPtigabaCFnRQnrQs= Authentication-Results: mail-nwsmtp-smtp-production-main-18.iva.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <48c4333a-8c47-4bf9-322c-1621cd876968@yandex.ru> Date: Tue, 27 Jun 2023 21:20:31 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH 2/3] fd/locks: allow get the lock owner by F_OFD_GETLK Content-Language: en-US To: Jeff Layton , Christian Brauner Cc: linux-kernel@vger.kernel.org, Chuck Lever , Alexander Viro , linux-fsdevel@vger.kernel.org, Matthew Wilcox References: <5f644a24-90b5-a02f-b593-49336e8e0f5a@yandex.ru> <2eb8566726e95a01536b61a3b8d0343379092b94.camel@kernel.org> <9c0a7cde-da32-bc09-0724-5b1387909d18@yandex.ru> <26dce201000d32fd3ca1ca5b5f8cd4f5ae0b38b2.camel@kernel.org> <0188af4b-fc74-df61-8e00-5bc81bbcb1cc@yandex.ru> <20230623-paranoia-reinschauen-329185eac276@brauner> <0697f0d1-490b-6613-fea0-967a40861b25@yandex.ru> <51e756daf978ba61fbc15f209effac5daf59137a.camel@kernel.org> From: stsp In-Reply-To: <51e756daf978ba61fbc15f209effac5daf59137a.camel@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 27.06.2023 21:00, Jeff Layton пишет: > Beyond all of this, there is a long history of problems with the l_pid > field as well with network filesystems, even with traditional POSIX > locks. What should go into the l_pid when a traditional POSIX lock is > held by a process on a separate host? > > While POSIX mandates it, the l_pid is really sort of a "legacy" field > that is really just for informational purposes only nowadays. It might > have been a reliable bit of information back in the 1980's, but even > since the 90's it was suspect as a source of information. > > Even if you _know_ you hold a traditional POSIX lock, be careful > trusting the information in that field. Thanks for info. Additional problem with multiple owners that I can think of, is that you don't know if more owners are present. And even if you use SIGKILL to "iterate", you still don't know if you got another owner of the prev lock, or maybe you got entirely different read lock with the same range from another owner. Still if you do "man fcntl" you'll see this:                pid_t l_pid;     /* PID of process blocking our lock                                    (set by F_GETLK and F_OFD_GETLK) */ And no, its not my patch that did this. :) So unless properly documented, this would be treated as a bug. And it should _not_ be documented as "OFD locks has no owner by definition" or alike - no one buys that.