Received: by 10.223.185.116 with SMTP id b49csp8139338wrg; Thu, 1 Mar 2018 18:23:25 -0800 (PST) X-Google-Smtp-Source: AG47ELtCJx8VlkpEsvXubH/29xKW7I1W/l+NluDRdwmvYkJAvvDyRdIGAaFl35uePscQ4Uel0rw/ X-Received: by 10.99.178.94 with SMTP id t30mr3217505pgo.441.1519957405387; Thu, 01 Mar 2018 18:23:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519957405; cv=none; d=google.com; s=arc-20160816; b=BKbYiBtY5Qvbvdm9WkV7fpkq5hRSZrDG42esVNEreHJbozW6i2gTkwXA8/xQomTw60 uO82rTAHpHbbsiK//ARzIelPe0kvCCV1wJclUZ0m5Tszlv/0qGzd/V4FSWqK/UnnkGwV fnhA/UKcb491QItQb26YWHjM1fU3xxAHwQadeUMorlbprKtzW3eoDfg/YYQfo+eZc5D/ Yl66wTU3G30nfGfI9BzM0XQj/Wd1g7tX4v2pI8sK85c8GVxkjU8YWtDljkD/ITPaKgjN faCDQasAu68uIh4T0atnpgNDuGNLhhqiQdNJyhSUEva8SHXl2RZ30yTfBcngTLe0Q79t n9uQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:arc-authentication-results; bh=SDjSh6qVEcilQkjl1dJvMkW64qhCROFgYitVUH+HTO8=; b=ip1opwaSNZ0SKwuTYL7XEhJDy0qUyIJ/twePOMFvfutTjUwcjuIqeBK8ttBxlNWxgL WgkmT7l8Ef1vxfTY+Z/PZxueeBvSNbqo8L6PkQn17oQGJLFYHA86A5fmGgP24zvWoQow 9NdCaQCRq//1U5NKzqtmE77E1UPP6BVoGbovio0WUM0GiSPNSJSyVFSaESoJ47yQOp/v v5sISNfnes9eMqR6WBopeLL9a1Ug4MV8QcolkbdrZdk/hBQB66lXTpIc7F8L1iwFA+kJ UcVGJLbj+v6SNXMiCM2QfRGhM9A96qimv+ApB2tt/UgtN9HamyP1gVKZLvQk/lyDfy/O i75w== 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 89-v6si4003764pld.729.2018.03.01.18.23.10; Thu, 01 Mar 2018 18:23:25 -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 S1164182AbeCBCPy (ORCPT + 99 others); Thu, 1 Mar 2018 21:15:54 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:54252 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1163939AbeCBCPw (ORCPT ); Thu, 1 Mar 2018 21:15:52 -0500 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 37D93FC72D904; Fri, 2 Mar 2018 10:15:39 +0800 (CST) Received: from [10.177.253.249] (10.177.253.249) by smtp.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.361.1; Fri, 2 Mar 2018 10:15:38 +0800 Subject: Re: [Ocfs2-devel] [PATCH] Correct a comment error To: Changwei Ge , Larry Chen , "mfasheh@versity.com" , "jlbec@evilplan.org" References: <20180228101720.20725-1-lchen@suse.com> <5A97F88E.4010303@huawei.com> <63ADC13FD55D6546B7DECE290D39E373F292C0FC@H3CMLB12-EX.srv.huawei-3com.com> CC: "linux-kernel@vger.kernel.org" , "ocfs2-devel@oss.oracle.com" From: piaojun Message-ID: <5A98B3BB.3040408@huawei.com> Date: Fri, 2 Mar 2018 10:15:23 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <63ADC13FD55D6546B7DECE290D39E373F292C0FC@H3CMLB12-EX.srv.huawei-3com.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.253.249] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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 >> > . >