Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp7122837rwb; Mon, 12 Dec 2022 10:18:30 -0800 (PST) X-Google-Smtp-Source: AA0mqf64g2rKo0pIf0o9x7CaSYum9FIgmTIv/7bHdJqZXVwAvhuhFxQXAGpUE5dsFrrHpSvEUpEC X-Received: by 2002:a17:902:e812:b0:189:8a45:8e31 with SMTP id u18-20020a170902e81200b001898a458e31mr25409846plg.15.1670869110232; Mon, 12 Dec 2022 10:18:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670869110; cv=none; d=google.com; s=arc-20160816; b=RqyWyvwSV3SvTsCPbfBEVscTHmABf0mQ3tz7+2zhWxbyk+EpTgK2TpE3MAAVy4zHWM btUrP5h0qv4hRtZuRDMlPJTqlERFxphD1uIcF5iKQEQn6hwyYS6KUCM0w3e/Hh14u+FD VfwOqRljN1135F7GobA5oi+KaCX1DSDCGjeHGMZUg/c5hZRHFgS0yzuQkL8sjSFxS6R9 METCo3p9+Jsnv01S85GWWB7DjZzB/RjlvZqiQe+9UDv98fX2gZRzmVXsbD2yVbyTeUAQ GweYcpZPg+0c4sB71freke6iHi9f84UO7iZUZODuXJJ9RxRohNifzkKkVyBAWPPxH6UF hyBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=GeX6QG8bAXPsmOO88LgQ/PI9pedX5OeuJ8nmc7sUT7s=; b=BQoxG8orygDt2VGR7CDgPA51+Gy/sXypf9kRfcvzgwT0e0eY0GyAn6G02gjzchmOsa 7M0W3ACxkfWKd2k6wN67ayX5sNaXJZRKMTSb7KqduNEWiCSghKWR+id9AW5fsV5ELvAZ y8BzS/4ff9opjgMmbGlVPsIylm8I+GU4AQqMtrEAnKg7K2h9nf5UzwnR4voffR9S7DXo +Q6XOdykOaXaJycNNMymN2wAYiOWYu9o1SViXJelhaYY/ZYD8xiouE9cWwJoRyFi9Y2J Kp6IpEdBrme5vR//IHXJGoln1JIDSpuETb1JyLHfqX+kiM+v5X0t+XxJsjAv7/9yJPWv BzQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ZWV48V7V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jg7-20020a17090326c700b001891ad7051fsi9496449plb.165.2022.12.12.10.18.20; Mon, 12 Dec 2022 10:18:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ZWV48V7V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232859AbiLLR5K (ORCPT + 74 others); Mon, 12 Dec 2022 12:57:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232991AbiLLR5I (ORCPT ); Mon, 12 Dec 2022 12:57:08 -0500 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 718206415; Mon, 12 Dec 2022 09:57:06 -0800 (PST) Received: by mail-ej1-x633.google.com with SMTP id qk9so30140539ejc.3; Mon, 12 Dec 2022 09:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GeX6QG8bAXPsmOO88LgQ/PI9pedX5OeuJ8nmc7sUT7s=; b=ZWV48V7VzwltAnTDMELXcIUUWNDwAEj7eSzSn5ULUETh9htM3YAdqSI1+dyr7qz7xJ Hpdyc/vCtA90XgEDgUqGCOM/lxBr0lpYDavWp+5EzdbJF2MeoVJWNH5160vsdbSteX4/ /G3fACqTZ/fCOIr22dE19idCSlJw+V1b+i1n9C4bdSsUMrUtMR/01fL4NUUZc84fQ2ZB HiY0HbkzlexVbzfxDIOf98pe3KNWJxBQxvr/xmGkuoui0pmVXJKFiilGcRbhvK7YfNDF UojTc0nTXfBmOV0EG8K2OuJZDqhRwhGG1gf576/r/XMsh+dryiOJcKEX0pEvHixJccqF WaXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GeX6QG8bAXPsmOO88LgQ/PI9pedX5OeuJ8nmc7sUT7s=; b=4cTmLgeN4Ls4oUv8fyHGA24KiB0KjISYYciarkZv4DG08UAsyKzgDjMZxH7pRK0Nhz imwJPjCmDOlBMfuJbZnXGkw4wklMP0xYKmeSmeLshaLMS8M3S7sBcWgYxWgEMcHRdFnn L947IBZ1uCBlW23R1ytGNJ4etL2eLvMZLnjcHMpLFJY9H9VkT1XOR4p97m0Ruo5x/mgk u1hrM2pJXDy+mMkfopVL2gU+BVXE3crEm99ldFVHINw6Kcq9AEmZdYsRcyRjS9viDjJP j1cxmHhr33ttYAZ+3+c1m6LYgNdcaR/RzkVCZent3FL8wqzGwA6o0ju3xIRgQNJ5eKbl 3ueQ== X-Gm-Message-State: ANoB5pkSm+S86EYOtgVHXiIk9MzpTd8wPCmExF3yKBkoqOVKtJUin2xh k0gB5sjwQ8NVcts8lUtpOefIPGB8TlcuUdCT4HY= X-Received: by 2002:a17:906:28db:b0:7c1:4a75:a3a7 with SMTP id p27-20020a17090628db00b007c14a75a3a7mr850236ejd.171.1670867824936; Mon, 12 Dec 2022 09:57:04 -0800 (PST) MIME-Version: 1.0 References: <20221118020642.472484-1-xiubli@redhat.com> <20221118020642.472484-3-xiubli@redhat.com> In-Reply-To: <20221118020642.472484-3-xiubli@redhat.com> From: Ilya Dryomov Date: Mon, 12 Dec 2022 18:56:52 +0100 Message-ID: Subject: Re: [PATCH 2/2 v3] ceph: add ceph_lock_info support for file_lock To: xiubli@redhat.com Cc: ceph-devel@vger.kernel.org, jlayton@kernel.org, lhenriques@suse.de, mchangir@redhat.com, viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 18, 2022 at 3:07 AM wrote: > > From: Xiubo Li > > When ceph releasing the file_lock it will try to get the inode pointer > from the fl->fl_file, which the memory could already be released by > another thread in filp_close(). Because in VFS layer the fl->fl_file > doesn't increase the file's reference counter. > > Will switch to use ceph dedicate lock info to track the inode. > > And in ceph_fl_release_lock() we should skip all the operations if > the fl->fl_u.ceph_fl.fl_inode is not set, which should come from > the request file_lock. And we will set fl->fl_u.ceph_fl.fl_inode when > inserting it to the inode lock list, which is when copying the lock. > > Cc: stable@vger.kernel.org > Cc: Jeff Layton > URL: https://tracker.ceph.com/issues/57986 > Signed-off-by: Xiubo Li > --- > fs/ceph/locks.c | 20 ++++++++++++++++++-- > include/linux/ceph/ceph_fs_fl.h | 17 +++++++++++++++++ > include/linux/fs.h | 2 ++ > 3 files changed, 37 insertions(+), 2 deletions(-) > create mode 100644 include/linux/ceph/ceph_fs_fl.h > > diff --git a/fs/ceph/locks.c b/fs/ceph/locks.c > index b191426bf880..621f38f10a88 100644 > --- a/fs/ceph/locks.c > +++ b/fs/ceph/locks.c > @@ -34,18 +34,34 @@ static void ceph_fl_copy_lock(struct file_lock *dst, struct file_lock *src) > { > struct inode *inode = file_inode(dst->fl_file); > atomic_inc(&ceph_inode(inode)->i_filelock_ref); > + dst->fl_u.ceph_fl.fl_inode = igrab(inode); > } > > +/* > + * Do not use the 'fl->fl_file' in release function, which > + * is possibly already released by another thread. > + */ > static void ceph_fl_release_lock(struct file_lock *fl) > { > - struct inode *inode = file_inode(fl->fl_file); > - struct ceph_inode_info *ci = ceph_inode(inode); > + struct inode *inode = fl->fl_u.ceph_fl.fl_inode; > + struct ceph_inode_info *ci; > + > + /* > + * If inode is NULL it should be a request file_lock, > + * nothing we can do. > + */ > + if (!inode) > + return; > + > + ci = ceph_inode(inode); > if (atomic_dec_and_test(&ci->i_filelock_ref)) { > /* clear error when all locks are released */ > spin_lock(&ci->i_ceph_lock); > ci->i_ceph_flags &= ~CEPH_I_ERROR_FILELOCK; > spin_unlock(&ci->i_ceph_lock); > } > + fl->fl_u.ceph_fl.fl_inode = NULL; > + iput(inode); > } > > static const struct file_lock_operations ceph_fl_lock_ops = { > diff --git a/include/linux/ceph/ceph_fs_fl.h b/include/linux/ceph/ceph_fs_fl.h > new file mode 100644 > index 000000000000..ad1cf96329f9 > --- /dev/null > +++ b/include/linux/ceph/ceph_fs_fl.h > @@ -0,0 +1,17 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * ceph_fs_fl.h - Ceph lock info > + * > + * LGPL2 > + */ > + > +#ifndef CEPH_FS_FL_H > +#define CEPH_FS_FL_H > + > +#include > + > +struct ceph_lock_info { > + struct inode *fl_inode; > +}; > + > +#endif > diff --git a/include/linux/fs.h b/include/linux/fs.h > index d6cb42b7e91c..2b03d5e375d7 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -1066,6 +1066,7 @@ bool opens_in_grace(struct net *); > > /* that will die - we need it for nfs_lock_info */ > #include > +#include > > /* > * struct file_lock represents a generic "file lock". It's used to represent > @@ -1119,6 +1120,7 @@ struct file_lock { > int state; /* state of grant or error if -ve */ > unsigned int debug_id; > } afs; > + struct ceph_lock_info ceph_fl; Hi Xiubo and Jeff, Xiubo, instead of defining struct ceph_lock_info and including a CephFS-specific header file in linux/fs.h, I think we should repeat what was done for AFS -- particularly given that ceph_lock_info ends up being a dummy type that isn't mentioned anywhere else. Jeff, could you please ack this with your file locking hat on? Thanks, Ilya