Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp271031imd; Fri, 2 Nov 2018 23:31:42 -0700 (PDT) X-Google-Smtp-Source: AJdET5cpuUCi149HBy9HY4EbkHcMeDbmRdgs675N3028bzrTHc3y5HR8rM321XxKuEdMsDVTRXtD X-Received: by 2002:a63:c60d:: with SMTP id w13-v6mr13603075pgg.261.1541226702206; Fri, 02 Nov 2018 23:31:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541226702; cv=none; d=google.com; s=arc-20160816; b=wqfCC1m5Z6ThVU1SVwtdk8G7eqOsyb/5/EsU+lO3oUVT1gMK9nqB8rPv9mm1MQPpyV 58b5zTmQIuX5y5Sv/xdWI5KWt0Yg6ncmGsG/iQkjQyJPBZzqq2l+7OEevyxcSIUXelnD wgVkkUZaJfhNdPFsEVQE6VjvjGbiwbX/U1hZtI40Bi3qPv7lsaKAe9ahP/8sDJB+tWSd wSjj4dCkZFuuJMJUNT4wAT98LaWCT5ksKITxnWJOlNbcBXtB4sT98Xrhl2gMZ4zfNxNR 5xiBY7gXV+Puadr7gjzi7zKA1HKrw5qxmLQm0ghzP3ETdc/ZtZqJXfaffuACvQTKCtA+ ZLlA== 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:references:cc:to :subject; bh=2JJOlVLMuYJY9obTa6/kFnGXIKuGk/f8x5EyOi00T0k=; b=lPbm7Lib+AJYkBJe2rW1bwAX/fUWXSr9vCF/L2BaUkHAQpDDGFtZi/4MxzK1KNxnOp xJn+2GlYawrmPs+nCBfAmsklnj85OvqW6MreF77Tme1DYn24KtzRJQcjGQNLnxIptPNY uAyThiV/IE73AGlyvGb3V9jk51ndy1ZrWQjxJQQzdc1AW8HcTu6CBAZJ6bu348gIe9t/ PuWfHtT7tKRUP5Kc8aTxec3XZDYaLCeYJ4vot8RXePFvh0RbR+kICJxRnNJ9LIKDzimI Gc/hYYSSZaa2XKkKj6XpXun0SOGPS1SbSW0/BGogDw3ZRhQBLu1CNnsWcJYJyraw3aiu 5Vrw== 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 t19-v6si7210674plj.37.2018.11.02.23.31.27; Fri, 02 Nov 2018 23:31:42 -0700 (PDT) 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 S1727713AbeKCPk7 (ORCPT + 99 others); Sat, 3 Nov 2018 11:40:59 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:59548 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726129AbeKCPk7 (ORCPT ); Sat, 3 Nov 2018 11:40:59 -0400 Received: from DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 52A848C58AD9C; Sat, 3 Nov 2018 14:30:42 +0800 (CST) Received: from [10.151.23.176] (10.151.23.176) by smtp.huawei.com (10.3.19.209) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 3 Nov 2018 14:30:41 +0800 Subject: Re: [git pull] mount API series To: Al Viro CC: Linus Torvalds , , , , , , "Linux Kernel Mailing List" References: <20181031053355.GQ32577@ZenIV.linux.org.uk> <28156.1541092687@warthog.procyon.org.uk> <3549.1541116763@warthog.procyon.org.uk> <20181102040701.GX32577@ZenIV.linux.org.uk> From: Gao Xiang Message-ID: <2bc0d9c2-bd62-5a5b-7d92-011c688b9ab5@huawei.com> Date: Sat, 3 Nov 2018 14:30:01 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20181102040701.GX32577@ZenIV.linux.org.uk> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.151.23.176] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Al, On 2018/11/2 12:07, Al Viro wrote: > On Thu, Nov 01, 2018 at 11:59:23PM +0000, David Howells wrote: > >> (*) mount-api-core. These are the internal-only patches that add the >> fs_context, the legacy wrapper and the security hooks and make certain >> filesystems make use of it. > > FWIW, while rereading that series I'd spotted something very odd in erofs. > It's orthogonal to everything else, but just to make sure it doesn't get > lost: > * sbi->dev_name thing in erofs is used only for debugging printks, > basically. Just use sb->s_id[] and be done with that. > * dump struct erofs_mount_private - you don't need dev_name in > your erofs_fill_super(). Just use mount_bdev() in usual fashion. OK, these two points are the same, the original alternative patch to fixup it is to use bdevname(), However I saw what is done in drivers/usb/gadget/function/f_fs.c, therefore I fixed in as what I saw in f_fs.c. Refer: https://lists.ozlabs.org/pipermail/linux-erofs/2018-September/000548.html https://lists.ozlabs.org/pipermail/linux-erofs/2018-September/000551.html I could remove erofs_mount_private entirely if you want. :) > * what the hell are you doing with ->s_root??? Why would you > possibly want it hashed and what kind of dcache lookup could find it? > That d_rehash() looks deeply confused; what are you trying to do there? Thanks for pointing out. After I think into this piece of code, I also think that is redundant. I will fix it immediately, thanks again for pointing out. Thanks, Gao Xiang >