Received: by 10.223.164.202 with SMTP id h10csp154245wrb; Wed, 29 Nov 2017 19:06:04 -0800 (PST) X-Google-Smtp-Source: AGs4zMaD7mwzY9NqKeWzbvYIpfS6p3a/1Pqb1yQ5oQmGsiRASQQWkWsFUrZYtYt9hNgOKlIzhQum X-Received: by 10.84.131.40 with SMTP id 37mr1079440pld.302.1512011164496; Wed, 29 Nov 2017 19:06:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512011164; cv=none; d=google.com; s=arc-20160816; b=lOYEmfCsyGb4UkRCFTEtvchJETk4OKbZo66fzKmpYi0RDDpaO5mXZDT9CTSv6RbUV/ P3VULTKyzEDLzZDBM9uxFNA0BpRXrdvG6FOvqUYhubDlz+iSmhoNY3FGqzkTeWXY9dnL GQBTTNP5TMvgD1dAImo7vqqFngYNFh/md3e+GzzkM+TflM//cK57TJATvT6EmZc4Wznj Rous6qYedVLjsLGuAPTpq21MPiTl0fJ+g5Yh4NYO7JeJZNNKTQFxnDcEmf8y8uFyFj7z ThrNV5e7KUyxf7cLz9YJ2LnM6GCNGWxKU21lam9ilBij+J0jPG52ylL0vqTgiKiRJAT+ 1FmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:references:message-id:date :thread-index:thread-topic:subject:cc:to:from :arc-authentication-results; bh=6rDxnqOU8Hyuy2pLDS/o6wRJwbkyu/Qwm7318D8FotI=; b=oXjc7IsYy2I9zGSVLlVnxksdMY6o+8PSF5EV+5YpyIPwHdHOLdaJwXu/A7hwS/IpF+ wMcniKMSle90/4byL8yphS5LmAR5xyhJPlwCKADMtgOIsfzVAKiBhkZ4KsrUc1+u8SfX a/uyU8ZNLldB9PDTFQrTsZ+McsxOLgNuEYZEpac38GmeeLs8XW6Lzbmo2CxLNb5JU+n2 jkxAcGYnOBUYABgjAfq6qNmhTxMdWyUv0cht8abj0j9Wx0xq7VYFoDcun+aXmreyKbro L/flIKTLyXtWyse9cLMaRgiJPrF8qTNGVRkO+Brf58Rz2J5IHdTQ+A9P8izDyPPvpGu4 6eow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c2si2251398plb.787.2017.11.29.19.05.50; Wed, 29 Nov 2017 19:06:04 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753279AbdK3DFh convert rfc822-to-8bit (ORCPT + 99 others); Wed, 29 Nov 2017 22:05:37 -0500 Received: from smtp.h3c.com ([60.191.123.56]:65098 "EHLO h3cmg01-ex.h3c.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752193AbdK3DFe (ORCPT ); Wed, 29 Nov 2017 22:05:34 -0500 Received: from BJHUB02-EX.srv.huawei-3com.com (unknown [10.63.20.170]) by h3cmg01-ex.h3c.com with smtp id 237e_01f4_d1a42b4f_74e7_413c_9d44_ed8cc88b819b; Thu, 30 Nov 2017 11:01:46 +0800 Received: from H3CMLB14-EX.srv.huawei-3com.com ([fe80::f804:6772:bd71:f07f]) by BJHUB02-EX.srv.huawei-3com.com ([::1]) with mapi id 14.03.0248.002; Thu, 30 Nov 2017 11:01:14 +0800 From: Changwei Ge To: Gang He , "jlbec@evilplan.org" , "hch@lst.de" , Goldwyn Rodrigues , "mfasheh@versity.com" CC: "ocfs2-devel@oss.oracle.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Ocfs2-devel] [PATCH v2 1/3] ocfs2: add ocfs2_try_rw_lock and ocfs2_try_inode_lock Thread-Topic: [Ocfs2-devel] [PATCH v2 1/3] ocfs2: add ocfs2_try_rw_lock and ocfs2_try_inode_lock Thread-Index: AQHTaQn+nx4TZchGSkq+SGn4Y3At8w== Date: Thu, 30 Nov 2017 03:01:13 +0000 Message-ID: <63ADC13FD55D6546B7DECE290D39E373F1483A9C@H3CMLB14-EX.srv.huawei-3com.com> References: <1511944612-9629-1-git-send-email-ghe@suse.com> <1511944612-9629-2-git-send-email-ghe@suse.com> <63ADC13FD55D6546B7DECE290D39E373F147CA86@H3CMLB14-EX.srv.huawei-3com.com> <5A1FE111020000F90009B606@prv-mh.provo.novell.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.125.136.231] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Gang, On 2017/11/30 10:45, Gang He wrote: > Hello Changwei, > > >>>> >> On 2017/11/29 16:38, Gang He wrote: >>> Add ocfs2_try_rw_lock and ocfs2_try_inode_lock functions, which >>> will be used in non-block IO scenarios. >>> >>> Signed-off-by: Gang He >>> --- >>> fs/ocfs2/dlmglue.c | 21 +++++++++++++++++++++ >>> fs/ocfs2/dlmglue.h | 4 ++++ >>> 2 files changed, 25 insertions(+) >>> >>> diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c >>> index 4689940..a68efa3 100644 >>> --- a/fs/ocfs2/dlmglue.c >>> +++ b/fs/ocfs2/dlmglue.c >>> @@ -1742,6 +1742,27 @@ int ocfs2_rw_lock(struct inode *inode, int write) >>> return status; >>> } >>> >>> +int ocfs2_try_rw_lock(struct inode *inode, int write) >>> +{ >>> + int status, level; >>> + struct ocfs2_lock_res *lockres; >>> + struct ocfs2_super *osb = OCFS2_SB(inode->i_sb); >>> + >>> + mlog(0, "inode %llu try to take %s RW lock\n", >>> + (unsigned long long)OCFS2_I(inode)->ip_blkno, >>> + write ? "EXMODE" : "PRMODE"); >>> + >>> + if (ocfs2_mount_local(osb)) >>> + return 0; >>> + >>> + lockres = &OCFS2_I(inode)->ip_rw_lockres; >>> + >>> + level = write ? DLM_LOCK_EX : DLM_LOCK_PR; >>> + >>> + status = ocfs2_cluster_lock(osb, lockres, level, DLM_LKF_NOQUEUE, 0); >> >> Hi Gang, >> Should we consider about passing a flag - OCFS2_LOCK_NONBLOCK to >> ocfs2_cluster_lock. Otherwise a cluster locking progress may be waiting >> for accomplishment of DC, which I think violates _NO_WAIT_ semantics. > > If ocfs2 is a local file system, we should not wait for any condition, but for a cluster file system, > we cannot avoid this totally according to the current DLM lock design, we need to wait for a little to get lock for the first time. > Why do we not use OCFS2_LOCK_NONBLOCK flag to get a lock? > since this flag is not stable to get a lock no matter this lock is occupied by other nodes, or not. I suppose local node must be granted under the condition that it is marked with *OCFS2_LOCK_BLOCKED*. And the control flag _OCFS2_LOCK_NONBLOCK_ will make lock progress directly return -EAGAIN without any waiting. > If you use OCFS2_LOCK_NONBLOCK flag to get a fresh lock, you possibly fail or success, depends on when the lock acquisition callback happens. > So, I think DLM_LKF_NOQUEUE flag should be more matched to _NO_WAIT_ semantics. I thinks OCFS2_LOCK_NONBLOCK doesn't conflict DLM_LKF_NOQUEUE, they are the forth and fifth argument respectively. > we always get a fresh lock successfully, always failed if the lock is/was occupied by other nodes. What do you mean by a fresh lock? A lock that is never granted or acquired? If a lock is marked with OCFS2_LOCK_BLOCKED, local node must has acquired it. Thanks, Changwei > This flag can give us a consistent locking behavior. > > Thanks > Gang > > > >> >> Thanks, >> Changwei. >> >>> + return status; >>> +} >>> + >>> void ocfs2_rw_unlock(struct inode *inode, int write) >>> { >>> int level = write ? DLM_LOCK_EX : DLM_LOCK_PR; >>> diff --git a/fs/ocfs2/dlmglue.h b/fs/ocfs2/dlmglue.h >>> index a7fc18b..05910fc 100644 >>> --- a/fs/ocfs2/dlmglue.h >>> +++ b/fs/ocfs2/dlmglue.h >>> @@ -116,6 +116,7 @@ void ocfs2_refcount_lock_res_init(struct ocfs2_lock_res >> *lockres, >>> int ocfs2_create_new_inode_locks(struct inode *inode); >>> int ocfs2_drop_inode_locks(struct inode *inode); >>> int ocfs2_rw_lock(struct inode *inode, int write); >>> +int ocfs2_try_rw_lock(struct inode *inode, int write); >>> void ocfs2_rw_unlock(struct inode *inode, int write); >>> int ocfs2_open_lock(struct inode *inode); >>> int ocfs2_try_open_lock(struct inode *inode, int write); >>> @@ -140,6 +141,9 @@ int ocfs2_inode_lock_with_page(struct inode *inode, >>> /* 99% of the time we don't want to supply any additional flags -- >>> * those are for very specific cases only. */ >>> #define ocfs2_inode_lock(i, b, e) ocfs2_inode_lock_full_nested(i, b, e, 0, >> OI_LS_NORMAL) >>> +#define ocfs2_try_inode_lock(i, b, e)\ >>> + ocfs2_inode_lock_full_nested(i, b, e, OCFS2_META_LOCK_NOQUEUE,\ >>> + OI_LS_NORMAL) >>> void ocfs2_inode_unlock(struct inode *inode, >>> int ex); >>> int ocfs2_super_lock(struct ocfs2_super *osb, >>> > > From 1585457449645651820@xxx Thu Nov 30 02:47:29 +0000 2017 X-GM-THRID: 1585212200939154586 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread