Received: by 10.223.185.116 with SMTP id b49csp8151312wrg; Thu, 1 Mar 2018 18:41:12 -0800 (PST) X-Google-Smtp-Source: AG47ELulg62PSdYgDQg0XYCWwhlYVDAQA9mBzXnSRFDW6Ns0KX3tIHxe8Xz/UYJR1Vw9zSC/PuBr X-Received: by 10.99.146.91 with SMTP id s27mr3266679pgn.367.1519958471887; Thu, 01 Mar 2018 18:41:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519958471; cv=none; d=google.com; s=arc-20160816; b=N6dUqMPlapxht673/VztCI/n/s0Qfy6GN1vPGTv7JHDpNcLMLARZVzGovcu5S+oGxc OC5iUnTIRa0o+23QPh0Mt70FfBhcw0QiN/wvTVCZxepjARFEn/8RkPnRW3CCGci0o2Oe DZT+rQu5I1YsFP+a8u0jQIlXEMiGWpyDxHfiYjIEm/40bLlOOfBVwqTfGHh8ECo9b+rx RMx42fwqdoE8POyg8TWmOjxcVbG3gYMguYJ0NvrhQqvulYQyDEQRaFfu49qr9/fPRWwK hoHPcHLAdWZyXbR6vlLjI/VZGHfGokwLkfQDQGZuXsFcjC2LrTv7S6QIa5qU01+cGEkB tNkQ== 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=JtOUyH6PZGWICsIyxVrJf1olkOr9Q1fJH+Ac1BsIDDo=; b=AV6Ib159sKuMVT7DpFNwK/n8cN3OSHUAP8hiJoAH+CzRDoFtdPGfCAKM3+shYyKgGy LcxxQHh7nS2UtfuQ8hJb/tLwem7ylPfapO2Njwj0AL2Jr1ckTfgSgELj/rDWmSAYILSu +YsvPERm2geu7pjhg6EVDkYNCLRIUus+88P/RZORGF23CaXTuAMNe7ZCs5x8Kz/atYy7 0FB8GVqioQwmu1Idu1GjMn832FXeDbQZ8+ToHakSmInqGJNW2tE+CaGrVsvWMkgw9epi SlHGDHLZudJQHzuGe+JQ6VEkxNfMeSe5Hf5BffbT2K4PzCsM3wtWbMt1uTUSuXwG3p7K gqYw== 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 s4si1058955pfm.223.2018.03.01.18.40.57; Thu, 01 Mar 2018 18:41:11 -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 S1164406AbeCBCjq convert rfc822-to-8bit (ORCPT + 99 others); Thu, 1 Mar 2018 21:39:46 -0500 Received: from smtp.h3c.com ([60.191.123.56]:30106 "EHLO h3cmg01-ex.h3c.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1164293AbeCBCjp (ORCPT ); Thu, 1 Mar 2018 21:39:45 -0500 Received: from BJHUB02-EX.srv.huawei-3com.com (unknown [10.63.20.170]) by h3cmg01-ex.h3c.com with smtp id 6902_009e_a01eccaf_1911_41b1_b78f_1a25ab080223; Fri, 02 Mar 2018 10:38:58 +0800 Received: from H3CMLB12-EX.srv.huawei-3com.com ([fe80::10fe:abde:731b:fdde]) by BJHUB02-EX.srv.huawei-3com.com ([::1]) with mapi id 14.03.0248.002; Fri, 2 Mar 2018 10:38:47 +0800 From: Changwei Ge To: piaojun , Larry Chen , "mfasheh@versity.com" , "jlbec@evilplan.org" CC: "linux-kernel@vger.kernel.org" , "ocfs2-devel@oss.oracle.com" Subject: Re: [Ocfs2-devel] [PATCH] Correct a comment error Thread-Topic: [Ocfs2-devel] [PATCH] Correct a comment error Thread-Index: AQHTsH2KCDugZkjy6km/xN7cimww6Q== Date: Fri, 2 Mar 2018 02:38:46 +0000 Message-ID: <63ADC13FD55D6546B7DECE290D39E373F292C163@H3CMLB12-EX.srv.huawei-3com.com> References: <20180228101720.20725-1-lchen@suse.com> <5A97F88E.4010303@huawei.com> <63ADC13FD55D6546B7DECE290D39E373F292C0FC@H3CMLB12-EX.srv.huawei-3com.com> <5A98B3BB.3040408@huawei.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 Jun, On 2018/3/2 10:16, piaojun wrote: > Hi Changwei, > > On 2018/3/2 9:59, Changwei Ge wrote: >> Hi Jun, >> I think the comments for both two functions are OK. >> No need to rework them. >> As we know, ocfs2 lock name(lock id) are composed of several parts including >> block number. > I looked though the comments involved 'lockid', and found 'lockid' is a > concept in dlm level, so ocfs2 level should not be aware of it. I don't agree. Please refer to ocfs2_build_lock_name(). DLM should not know how ocfs2 distinguishes objects it wants to protected. Moreover, ocfs2 has a abstraction layer called dlmglue. -Changwei > > thanks, > Jun >> >> Thanks, >> Changw2ei >> >> On 2018/3/1 20:58, piaojun wrote: >>> Hi Larry, >>> >>> There is the same mistake in ocfs2_reflink_inodes_lock(), could you help >>> fixing them all? >>> >>> thanks, >>> Jun >>> >>> On 2018/2/28 18:17, Larry Chen wrote: >>>> The function ocfs2_double_lock tries to lock the inode with lower >>>> blockid first, not lockid. >>>> >>>> Signed-off-by: Larry Chen >>>> --- >>>> fs/ocfs2/namei.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c >>>> index c801eddc4bf3..30d454de35a8 100644 >>>> --- a/fs/ocfs2/namei.c >>>> +++ b/fs/ocfs2/namei.c >>>> @@ -1133,7 +1133,7 @@ static int ocfs2_double_lock(struct ocfs2_super *osb, >>>> if (*bh2) >>>> *bh2 = NULL; >>>> >>>> - /* we always want to lock the one with the lower lockid first. >>>> + /* we always want to lock the one with the lower blockid first. >>>> * and if they are nested, we lock ancestor first */ >>>> if (oi1->ip_blkno != oi2->ip_blkno) { >>>> inode1_is_ancestor = ocfs2_check_if_ancestor(osb, oi2->ip_blkno, >>>> >>> >>> _______________________________________________ >>> Ocfs2-devel mailing list >>> Ocfs2-devel@oss.oracle.com >>> https://oss.oracle.com/mailman/listinfo/ocfs2-devel >>> >> . >> >