Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3216418ybt; Mon, 29 Jun 2020 19:11:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJytkOpsnb3D0WoLq3x6lmo6G0r0rUHSkiEcAobqXShtNRHyqo8HAPHX9pq8cgOKnI/xEs8/ X-Received: by 2002:a17:906:bb0c:: with SMTP id jz12mr15920733ejb.27.1593483083301; Mon, 29 Jun 2020 19:11:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593483083; cv=none; d=google.com; s=arc-20160816; b=gvosPCHgwIYnP2LuazfNuGO34G6cbuhJU7gh7E9a0sW3CD17HOaHc2ODkBA8e9sn7h XZQTnLPiKqoVtXhC5kQ6XIJYNPuvQJDTW5fLllzNj1FlIKz/vSNp8C0h42idCOnkVAOW 2eo8GcGroo92L001S/eZvGEwDtYhTU95vr6BEo7lXzj+77dYfAzPLNzVxANGqF1iPfHr SIZ2cNpNZ/lvmWqht6rIlxrsXwB0kJGpuVDjC4dzMDDg8Gp5L70swe63MBT/TBvlb408 60u5Ue11BxIM7ZZNlRgQJAH4fgle1jtU48vJv8N1xxwCgU7KWxr6IXXLsPeSLXaSGzD6 mRuA== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=HR5V8grss6hZdNQcTfJ1vgYE9nHisFi4KwlTn4xM+gs=; b=dfhh7YafsO6eDe4kOJgLXT4QITluzcqvdREPZCqcOtpDmMAC+2NKrHxnOaXVsJLLCV fC7W66XDYweMLPXJJzV8yKL4L4ChRFfPp2ErFWPA93GmMrJ/UwEdGu3wQmbiKcsumtpC krMQyCN+MsvsSs85yoA4U/K2xjUQFjAwapx09DWmKk0uwXbdSgn4qVbzzEWuD5JoBei4 tV/66jS6QN6Ui8zQQZnKsO7/T3YbF8vIwM1nNj+ClIXipMZxQ+8EslvBpXEUQyLyiiyv pmW51rA4F7QM/ThawcbziPi3v/Ax5vm8kMVFdk0n6+tgkpQjACRApZKTYrG8tHWenFwv unNg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cf17si811723edb.488.2020.06.29.19.11.00; Mon, 29 Jun 2020 19:11:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726853AbgF3CKS (ORCPT + 99 others); Mon, 29 Jun 2020 22:10:18 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:46048 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726288AbgF3CKS (ORCPT ); Mon, 29 Jun 2020 22:10:18 -0400 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 767F9F4432087A4712BF; Tue, 30 Jun 2020 10:10:14 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.208) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 30 Jun 2020 10:10:10 +0800 Subject: Re: [f2fs-dev] [PATCH] f2fs: fix typo in comment of f2fs_do_add_link To: CC: Liu Song , , , References: <20200625124011.8072-1-fishland@aliyun.com> From: Chao Yu Message-ID: <31f8ff95-ad11-cb1c-fbf8-a9ddd450499d@huawei.com> Date: Tue, 30 Jun 2020 10:10:10 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200625124011.8072-1-fishland@aliyun.com> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jaegeuk, It looks we merge this patch with below wrong author, better to fix this Liu Song via Linux-f2fs-devel On 2020/6/25 20:40, Liu Song via Linux-f2fs-devel wrote: > stakable/stackable > > Signed-off-by: Liu Song > --- > fs/f2fs/dir.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c > index d35976785e8c..069f498af1e3 100644 > --- a/fs/f2fs/dir.c > +++ b/fs/f2fs/dir.c > @@ -779,7 +779,7 @@ int f2fs_do_add_link(struct inode *dir, const struct qstr *name, > return err; > > /* > - * An immature stakable filesystem shows a race condition between lookup > + * An immature stackable filesystem shows a race condition between lookup > * and create. If we have same task when doing lookup and create, it's > * definitely fine as expected by VFS normally. Otherwise, let's just > * verify on-disk dentry one more time, which guarantees filesystem >