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 1DD59EB64DB for ; Tue, 20 Jun 2023 12:34:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232674AbjFTMed (ORCPT ); Tue, 20 Jun 2023 08:34:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55618 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231805AbjFTMea (ORCPT ); Tue, 20 Jun 2023 08:34:30 -0400 Received: from forward502c.mail.yandex.net (forward502c.mail.yandex.net [178.154.239.210]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0764410DA; Tue, 20 Jun 2023 05:34:27 -0700 (PDT) Received: from mail-nwsmtp-smtp-production-main-63.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-63.sas.yp-c.yandex.net [IPv6:2a02:6b8:c14:6e01:0:640:627f:0]) by forward502c.mail.yandex.net (Yandex) with ESMTP id 0F98F5E8DC; Tue, 20 Jun 2023 15:34:22 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-63.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id 5Ygda0tDguQ0-z3EyeGZo; Tue, 20 Jun 2023 15:34:21 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1687264461; bh=djyFSMQCvvi3PtQek0qog/X/Y7hUR7MnMTmzr3nhW4g=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=nObO3tXw07UF99ZwPSgfjLyWQ6W5or7uUaW9qg/A9XS4ufoP7v0XmdeIhYXT3Q7jO 9036yWJW/zNO05uL8vNS0vIIV7gJvV5AESjcLKVqELuqzkDbjjAe1YdUNydqLiIcdQ Pn2aHPUXgrgschLMqNT6dzUSgnzMnImKEs2NAOOg= Authentication-Results: mail-nwsmtp-smtp-production-main-63.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Date: Tue, 20 Jun 2023 17:34:00 +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 , linux-kernel@vger.kernel.org Cc: Chuck Lever , Alexander Viro , Christian Brauner , linux-fsdevel@vger.kernel.org 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> From: stsp In-Reply-To: <2eb8566726e95a01536b61a3b8d0343379092b94.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 20.06.2023 17:02, Jeff Layton пишет: > Suppose I start a process (call it pid 100), and then spawn a thread > (101). I then have 101 open a file and set an OFD lock on it (such that > the resulting fl_pid field in the file_lock is set to 101). How come? There are multiple places in locks.c with this line: fl->fl_pid = current->tgid; And I've yet to see the line like: fl->fl_pid = current->pid; Its simply not there. No, we put tgid into l_pid! tgid will still be 100, no matter how many threads you spawn or destroy. Or what am I misseng? > That's just one example, of course. The underlying problem is that OFD > locks are not owned by processes in the same way that traditional POSIX > locks are, so reporting a pid there is unreliable, at best. But we report tgid. It doesn't depend on threads. I don't understand. :)