Received: by 10.223.185.116 with SMTP id b49csp8123925wrg; Thu, 1 Mar 2018 18:02:31 -0800 (PST) X-Google-Smtp-Source: AG47ELv4v88nZOdnQYL3nl7LXxX21ZNTrFBA3lJne9woxkDqUALozxOxHuGdEu42Bf77BHWXbCak X-Received: by 2002:a17:902:7c11:: with SMTP id x17-v6mr3770605pll.59.1519956151864; Thu, 01 Mar 2018 18:02:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519956151; cv=none; d=google.com; s=arc-20160816; b=aRgVlt2UAbllkgMrUDpDSSckDwlkhKSAY2z4zwZyBE4zzBFP3pxkqQs7LW4er8ythL ZrWVY4a2IpPiiLNYgsnw3svAkKeXh5sKvClYmZ8jpjqNfwplwhx+lXOrtRwzjohjmFUT qqyZcP4FHnAWHIZFe+AO3i+cx7VuToY1KxvkcyQgHajXUxdVNTvA2AP9s9pB6OEuZfpZ a60UKWrm6sHvv44IVGQ0Lktt2JChOLv7y/W08eFP7QqDBkiq5e7VNTD2EgqC3/4AZqpc 7GOu48GLnOWBtujiAm7SbpgxrX03NeLhPwqcnyx0FRmPGWh8OnUZVfBcjof4mHdTuEBS KOzw== 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=p+M8DLBv4hddWEGxhV0Tq3zjoSYEjE7YJRcD+FxfGaI=; b=f2CXzJW11SV+PNl/7Z0r4dYyXJMm+kMst1yFtLmfNITJNmT6WoTztIQP91cTzCVIj5 he83bxTdn0jw/r13pbU+qO55s6DWH1Lo7VDWSgUCPu7nsY5DzEh6ym0qAKiZCpDB8zOS s9jd8ibm00MJ7aJSEGY+TzWrO/4fvtfmmaxf35laIX78lA+srvVErzkisVi/tF+NYVRq +kKCEBSJOnUnt7OiwzRXkcp/uIBa0v5V/2A/ehcmGEsgP+7oxytO1B9Rd/Cdm82H1asL XturRfARwpbJ3WS+8tds0cRioMMbKElYF+hcVrTNLPyVZz8JhVxeQqPEN5yNqIMZa2En f18w== 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 n81si3968491pfb.320.2018.03.01.18.02.17; Thu, 01 Mar 2018 18:02:31 -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 S1164006AbeCBCAc convert rfc822-to-8bit (ORCPT + 99 others); Thu, 1 Mar 2018 21:00:32 -0500 Received: from smtp.h3c.com ([60.191.123.56]:29222 "EHLO h3cmg01-ex.h3c.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1164156AbeCBCAH (ORCPT ); Thu, 1 Mar 2018 21:00:07 -0500 Received: from BJHUB02-EX.srv.huawei-3com.com (unknown [10.63.20.170]) by h3cmg01-ex.h3c.com with smtp id 2ab3_04d8_4d029f41_9b3e_40cf_b1c2_8747ac9edaca; Fri, 02 Mar 2018 09:59:26 +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 09:59:17 +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 01:59:16 +0000 Message-ID: <63ADC13FD55D6546B7DECE290D39E373F292C0FC@H3CMLB12-EX.srv.huawei-3com.com> References: <20180228101720.20725-1-lchen@suse.com> <5A97F88E.4010303@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, 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. 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 >