Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp3328476ybh; Mon, 5 Aug 2019 16:35:24 -0700 (PDT) X-Google-Smtp-Source: APXvYqxA7TblKNDPVnXHBmZlWb4mFXpUbpMLM9TSTg+ccbIfOfUYu00ywMyK6c3R+nULYHiM2FJu X-Received: by 2002:a17:902:da4:: with SMTP id 33mr215302plv.209.1565048124325; Mon, 05 Aug 2019 16:35:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565048124; cv=none; d=google.com; s=arc-20160816; b=NvKV7EbMAOYG4B20Uia9IgJykwp4iJn7MSwr9CXm4WNZ6KvyFv5hy2afsdEF2NR6BJ ggskMCdk5FWdrMvHjMASJ5tUNE5CCPZNvE0j1J6OMqmqrIoOmx85EFTTDT/EAZpK2rHu Cw2aF717zwb1GOctKDB76nCgeaWEoOEH5hAXhR1m97YViJ8t7e1iXFGvSRCDWzSP7Mde HbzHbqP2DuMpA43VmaqnxfCYnct/sOYW6mG7h9XfSGOSGDGRRzVub9IHJjLngEJWBSpT ukN05jMTfJ7FYPlvKjgqMYDCvjqLYaoAqC8QGAfrFB7n8AjQYngymiSTcSLvaSh3uyUt BpNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=koiO6QWoree/nW+9pYGe3u6Me/mwGtXgJWRD09msP0Q=; b=aIu4MZ9G4uMOnd5ciE39DRxJps9RKSHh8hpVVjPMa37fEGwN0EW2xkU0xl1daoFn7Q pnOCVus0pVogFw2iL9pBWFcYZ01kjPOysqEWW64zOVmeo4LY6CvxaUyej6/gl0zfmykU a0dsSNfFt2vLO3sRruVY9+E5ZTAePD+w+eSgK8A5OTc9FBxlZNTZhBJ3U078XoTbIS3v msreig5BMhCZSFc8t3JZ0qQ/Vw1ywBWcBZCW5qxCyAvVvKxpPalCiMfroFcFW7VY3//J RqCv1xSKCPFlJE/pGXeAwp3Cn9BGAbkwsQ8ef9D2aDMkfEmIpPM4RNH6/vJWrnXsouCH yjnw== 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 35si42539912plb.62.2019.08.05.16.35.07; Mon, 05 Aug 2019 16:35:24 -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 S1730974AbfHEXeJ (ORCPT + 99 others); Mon, 5 Aug 2019 19:34:09 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:43698 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728483AbfHEXeJ (ORCPT ); Mon, 5 Aug 2019 19:34:09 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92 #3 (Red Hat Linux)) id 1humU9-0007b9-41; Mon, 05 Aug 2019 23:33:49 +0000 Date: Tue, 6 Aug 2019 00:33:49 +0100 From: Al Viro To: Sergey Senozhatsky Cc: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Chris Wilson , David Howells , Christoph Hellwig , David Airlie , Daniel Vetter , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCHv2 2/3] i915: convert to new mount API Message-ID: <20190805233349.GA27746@ZenIV.linux.org.uk> References: <20190805160307.5418-1-sergey.senozhatsky@gmail.com> <20190805160307.5418-3-sergey.senozhatsky@gmail.com> <20190805181255.GH1131@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190805181255.GH1131@ZenIV.linux.org.uk> User-Agent: Mutt/1.12.0 (2019-05-25) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 05, 2019 at 07:12:55PM +0100, Al Viro wrote: > On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote: > > tmpfs does not set ->remount_fs() anymore and its users need > > to be converted to new mount API. > > Could you explain why the devil do you bother with remount at all? > Why not pass the right options when mounting the damn thing? Incidentally, the only remaining modular user of get_fs_type() is the same i915_gemfs.c. And I wonder if we should aim for unexporting the damn thing instead of exporting put_filesystem()... Note that users in tomoyo and apparmor are bogus - they are in the instances of ill-defined method that needs to be split and moved, with the lookups (fs type included) replaced with callers passing the values they look up and will end up using. IOW, outside of core VFS we have very few legitimate users, and the one in kernel/trace might be better off as vfs_submount_by_name().