Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp5483307rwb; Mon, 14 Nov 2022 05:27:32 -0800 (PST) X-Google-Smtp-Source: AA0mqf5TRrQwmQCyT/JJ1V0LSe/nWWzhqEo4082kZd8N+45FaTPORrJv1fF5+fHEBMLp3Av8EYHf X-Received: by 2002:a05:6a00:1592:b0:56b:e2db:5b88 with SMTP id u18-20020a056a00159200b0056be2db5b88mr13681781pfk.27.1668432452341; Mon, 14 Nov 2022 05:27:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668432452; cv=none; d=google.com; s=arc-20160816; b=f1Arb8M6Q71The+QJhKkvWSXbTRNlSog5oiZJcUSHRcg2EtA3SkvQk0mfl4kRDXSEj Ca6pgzE1fSj1m58fob7XlWj+DP13RaHJsEDrxTLNIxPeaOrVEjkCVV6YZ5FeZojIP5K/ g88Byiy3klyQCcPla9qJVN9vF24xwRAT4u5lRm9oxFwRXX7XgGtyYiYfjP74/4VnvjEz dRZWf3X2fAsgllDtoF9uvo56LqoF2ilKyQfKV9MTeBHlRekS76vijks+u4eyWEo2h9Rw +20E0yUOKHai3PvZ3VD7Py4W+nGq4/HdtOsOCSrLp9dnOmxZKdHzXHikcWe6lZ/xx3R2 YCgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=XbnOKNFz0QFpr0L/BEERrr3p9C0lyZVLkIZ75c02Fh8=; b=Aaw2wiQ9clrXetX1FzzyvmYWFiDjE2216TBcDnT9rjiUwAf1+2ae8gm0Py3jkaDvt2 GD2g2KJSt6zGpRnJCMAK99xoFShHrQEc3eUAVaAjl5q19zcGGNBVxDgJbRk+eziW9ZCx oSHoi1iw8iGCgHerFRoQtKJao9jrjJ3pofrJkRQZRhKBnciLu7sRaa38Iooor1b41l72 DLi8mgrWkRMfhOyGEnzhzq39lYuqKxQKDTeJyRSz9AnMxJXAg+kDzlQ7AF2L7tIbcsQx 28p5xRxbT0S+RC3vweTiqFOodIfnbcCfK+bv7DqTxsu4tQ6H9cOmWkO0vQzREkLnT8ID YAMQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="Y/Tnewrh"; 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=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g184-20020a636bc1000000b0047060a43798si8797376pgc.461.2022.11.14.05.27.17; Mon, 14 Nov 2022 05:27:32 -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=@redhat.com header.s=mimecast20190719 header.b="Y/Tnewrh"; 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=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237701AbiKNNB2 (ORCPT + 87 others); Mon, 14 Nov 2022 08:01:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54014 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237687AbiKNNBS (ORCPT ); Mon, 14 Nov 2022 08:01:18 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B883A26493 for ; Mon, 14 Nov 2022 05:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668430819; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XbnOKNFz0QFpr0L/BEERrr3p9C0lyZVLkIZ75c02Fh8=; b=Y/TnewrhcWgbomFyrU7PB8mUZF8NmOthxHu6M2Q70l4yIuESurBvX69/NqVmvd0KfWudpc 9xwZEgcqtmK/e0U+mZqusQpkiAvTLfj140UHcJ4Y1BZsf6XOtYgQ2q3Dr4bzP0Qxi9YEBI k1w7Wvv6Kel4AuTW4NID4AcPoMf0KBU= Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-144-XczrTWOeNDOcDDO7m6qMsw-1; Mon, 14 Nov 2022 08:00:17 -0500 X-MC-Unique: XczrTWOeNDOcDDO7m6qMsw-1 Received: by mail-pj1-f71.google.com with SMTP id v10-20020a17090a7c0a00b00215deac75b4so5766419pjf.3 for ; Mon, 14 Nov 2022 05:00:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-language:content-transfer-encoding:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XbnOKNFz0QFpr0L/BEERrr3p9C0lyZVLkIZ75c02Fh8=; b=sSNu2t1oVP42jRdzlKHZlOqFS+3o6zC7+v05FKFRY15DI0Dfbswh228AqoWVwMmz+N DIK7Y9ytwu31DZ5fdZkOCGXPkskxrhENrsABXY+SQivSisqxMCBsKJD1V8rXKIbb47oR 9KEkSo0rL/tWqfhzOkq7+7IBCdAVBiqvnwGfKBMRRPFmkfj3ArIBfg6aRk+dF6yQLpR9 R/XAaqF0Q9dGpu5Ld7UWscsAu4qjy4fMEszU1tNnauPIgwaZNDcsLg75xD0gKExhzZpW yj3prnoUX5b1zDoR7MFISalJacXYr3k2Qq5P/K5VxNR0RjN2C/M+cga+D5swAyArdf27 lwZg== X-Gm-Message-State: ANoB5pnBieW4bvXk1ksYJcZ51ZiuAhvTgW7Rn0Rprcu4Xy/dGQqxg5N5 Y+4lDBXqrbSrJkC924EeeXPJHsrA0+9dgNmCU4r1U6G+XHAzwJnShdbaNnpVfaqLU2jy1MyIs7r kFNqG51h+5Hxl7cMXD7G4nZGN X-Received: by 2002:a17:902:6b87:b0:187:1a3f:d552 with SMTP id p7-20020a1709026b8700b001871a3fd552mr14015246plk.5.1668430816666; Mon, 14 Nov 2022 05:00:16 -0800 (PST) X-Received: by 2002:a17:902:6b87:b0:187:1a3f:d552 with SMTP id p7-20020a1709026b8700b001871a3fd552mr14015186plk.5.1668430816228; Mon, 14 Nov 2022 05:00:16 -0800 (PST) Received: from [10.72.12.148] ([43.228.180.230]) by smtp.gmail.com with ESMTPSA id n3-20020a17090ab80300b00210c84b8ae5sm6377845pjr.35.2022.11.14.05.00.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Nov 2022 05:00:15 -0800 (PST) Subject: Re: [PATCH 1/2 v2] ceph: add ceph_lock_info support for file_lock To: Jeff Layton , ceph-devel@vger.kernel.org, idryomov@gmail.com, viro@zeniv.linux.org.uk Cc: lhenriques@suse.de, mchangir@redhat.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, stable@vger.kernel.org References: <20221114051901.15371-1-xiubli@redhat.com> <20221114051901.15371-2-xiubli@redhat.com> From: Xiubo Li Message-ID: <46c13ca8-ed59-d033-cf7a-0c35770e7df0@redhat.com> Date: Mon, 14 Nov 2022 21:00:02 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE 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 14/11/2022 19:24, Jeff Layton wrote: > On Mon, 2022-11-14 at 13:19 +0800, xiubli@redhat.com 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 >> URL: https://tracker.ceph.com/issues/57986 >> Signed-off-by: Xiubo Li >> --- >> fs/ceph/locks.c | 18 +++++++++++++++--- >> include/linux/ceph/ceph_fs_fl.h | 26 ++++++++++++++++++++++++++ >> include/linux/fs.h | 2 ++ >> 3 files changed, 43 insertions(+), 3 deletions(-) >> create mode 100644 include/linux/ceph/ceph_fs_fl.h >> >> diff --git a/fs/ceph/locks.c b/fs/ceph/locks.c >> index 3e2843e86e27..d8385dd0076e 100644 >> --- a/fs/ceph/locks.c >> +++ b/fs/ceph/locks.c >> @@ -34,22 +34,34 @@ static void ceph_fl_copy_lock(struct file_lock *dst, struct file_lock *src) >> { >> struct ceph_file_info *fi = dst->fl_file->private_data; >> struct inode *inode = file_inode(dst->fl_file); >> + >> atomic_inc(&ceph_inode(inode)->i_filelock_ref); >> atomic_inc(&fi->num_locks); >> + dst->fl_u.ceph_fl.fl_inode = igrab(inode); >> } >> >> static void ceph_fl_release_lock(struct file_lock *fl) >> { >> struct ceph_file_info *fi = fl->fl_file->private_data; >> - struct inode *inode = file_inode(fl->fl_file); >> - struct ceph_inode_info *ci = ceph_inode(inode); >> - atomic_dec(&fi->num_locks); >> + 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); >> } >> + iput(inode); >> + atomic_dec(&fi->num_locks); > It doesn't look like this fixes the original issue. "fi" may be pointing > to freed memory at this point, right? Yeah, I didn't fix this in the this patch. I fixed it in a dedicated 2/2 patch. > I think you may need to get rid of > the "num_locks" field in ceph_file_info, and do that in a different way? > This is a dedicated field for each 'file' struct. I have no idea how to fix this in a different way yet. Thanks! - Xiubo >> } >> >> 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..02a412b26095 >> --- /dev/null >> +++ b/include/linux/ceph/ceph_fs_fl.h >> @@ -0,0 +1,26 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> +/* >> + * ceph_fs.h - Ceph constants and data types to share between kernel and >> + * user space. >> + * >> + * Most types in this file are defined as little-endian, and are >> + * primarily intended to describe data structures that pass over the >> + * wire or that are stored on disk. >> + * >> + * LGPL2 >> + */ >> + >> +#ifndef CEPH_FS_FL_H >> +#define CEPH_FS_FL_H >> + >> +#include >> + >> +/* >> + * Ceph lock info >> + */ >> + >> +struct ceph_lock_info { >> + struct inode *fl_inode; >> +}; >> + >> +#endif >> diff --git a/include/linux/fs.h b/include/linux/fs.h >> index e654435f1651..db4810d19e26 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; >> } fl_u; >> } __randomize_layout; >>