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 1F76DC001B0 for ; Fri, 23 Jun 2023 17:19:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232449AbjFWRTJ (ORCPT ); Fri, 23 Jun 2023 13:19:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232487AbjFWRSd (ORCPT ); Fri, 23 Jun 2023 13:18:33 -0400 Received: from forward500a.mail.yandex.net (forward500a.mail.yandex.net [178.154.239.80]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7FB922721; Fri, 23 Jun 2023 10:18:28 -0700 (PDT) Received: from mail-nwsmtp-smtp-production-main-31.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-31.vla.yp-c.yandex.net [IPv6:2a02:6b8:c18:58f:0:640:3768:0]) by forward500a.mail.yandex.net (Yandex) with ESMTP id EACBE5EA4E; Fri, 23 Jun 2023 20:18:25 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-31.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id NILcZOZDaGk0-S35Pwuwb; Fri, 23 Jun 2023 20:18:25 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1687540705; bh=kQSS/qORopd8NDqlspWE4bP9dR8P/jQxd/JVi56VTuY=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=Qh85RWDQ3psXAxoFrVkq5VLpFnk0QM7UCXiewRLIfwAQV99tDf0OhvRCE1Smaj8P5 XWtGT+0a9khrZntiHHI5jqdHtZKWkVWDzPpMTMR4qaI72hLcjcbMGaNNZQgZdLNqDN o8mW36AG/AEqCe6tQDVUBTQ+USc1W5y1eoyNREQg= Authentication-Results: mail-nwsmtp-smtp-production-main-31.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <0697f0d1-490b-6613-fea0-967a40861b25@yandex.ru> Date: Fri, 23 Jun 2023 22:18:23 +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: Christian Brauner , Jeff Layton 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> From: stsp In-Reply-To: <20230623-paranoia-reinschauen-329185eac276@brauner> 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 23.06.2023 20:25, Christian Brauner пишет: > On Wed, Jun 21, 2023 at 07:05:12AM -0400, Jeff Layton wrote: >> On Wed, 2023-06-21 at 15:42 +0500, stsp wrote: >>> 21.06.2023 15:35, Jeff Layton пишет: >>>> I don't think we can change this at this point. >>>> >>>> The bottom line (again) is that OFD locks are owned by the file >>>> descriptor (much like with flock()), and since file descriptors can be >>>> shared across multiple process it's impossible to say that some single >>>> process owns it. >>> What's the problem with 2 owners? >>> Can't you get one of them, rather than >>> meaningless -1? >>> Compare this situation with read locks. >>> They can overlap, so when you get an >>> info about a read lock (except for the >>> new F_UNLCK case), you get the info >>> about *some* of the locks in that range. >>> In the case of multiple owners, you >>> likewise get the info about about some >>> owner. If you iteratively send them a >>> "please release this lock" message >>> (eg in a form of SIGKILL), then you >>> traverse all, and end up with the >>> lock-free area. >>> Is there really any problem here? >> Yes. Ambiguous answers are worse than none at all. > I agree. > > A few minor observations: > > SCM_RIGHTS have already been mentioned multiple times. But I'm not sure > it's been mentioned explicitly but that trivially means it's possible to > send an fd to a completely separate thread-group, then kill off the > sending thread-group by killing their thread-group leader. Bad enough as > the identifier is now useless. But it also means that at some later > point that pid can be recycled. Come on. I never proposed anything like this. Of course the returned pid should be the pid of the current, actual owner, or one of current owners. If someone else proposed to return stalled pids, then it wasn't me.