Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp633992ybh; Sat, 3 Aug 2019 06:39:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqykfXXt4IOqCjL8rAr9YIEp77O4C8E0dsu70G45uW+Qoa+wL5ajKFR7wbuvDXpfYZYlRst3 X-Received: by 2002:a17:902:bc83:: with SMTP id bb3mr139511172plb.56.1564839543912; Sat, 03 Aug 2019 06:39:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564839543; cv=none; d=google.com; s=arc-20160816; b=gdnCy2IDaDEoDE6VeAXsC8m8hQu/oAHYSRgvRaw67we/wDnhHjWDvx56mcanLgWutp EpO4gYU0O2q4me1oYTnpMfDu5v2jYrGzS1FBgAeB//65+5qj90BdR4QXtnc7xPkJcmAT Zfdu4sD71fpZPy+t2R6Uzz6hPG1a22C6MPqvlgSoS7Xw3SwELN7TxPTptQm8DrMBCFm6 FD5JbZXRKa03bYAsN9y7G4TWu4uNc5n3U/AXXqriwjr3eOJZYlWKUscsiPrEUTtuO9b1 Z0dmxkZkxl/hDu0MNu5QBBWelOWwNxXOYI88676v18brLh5RVUmf0wDOaKor08e2+jKf GX1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:subject:user-agent:message-id :references:cc:in-reply-to:from:to:content-transfer-encoding :mime-version; bh=CRTXc8EE+jB/uNAAaZn7h3u5KkQpmHFEP5fjbpPTY7I=; b=bSUF6pTZ5/H9sKGbfnRAUrtxjuvXqq8mxZ38LmDDJZtWoMQim2aTdGZ7K0dghlqB/A hpxjLUik6/RPVVXXO0kThaDhYOewZkVpG5qhX4CK3O9c52VNdr9zdA8FIKP+2wrebMal fBbm5JGx3d7y1lqu11gYeKDpD4Qvasr+VN9u1t9zfs7WzuYJ4snGvxLx/f4drm5OqyTv nu7S7udDNQCPImqc9XwftFbt2fkAEslcmTI/kfPFO+XkZr0aI2gwoc10dlXqRtm7S6v3 SnzN9k/n06GmOsA5pVTCJuhj/9rP1vMcXdk6loyOWF6hbOEkAXF6pu5C5dSosgtKS0WH +qvQ== 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 l2si9307375pjw.0.2019.08.03.06.38.49; Sat, 03 Aug 2019 06:39:03 -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 S2405379AbfHBNlV convert rfc822-to-8bit (ORCPT + 99 others); Fri, 2 Aug 2019 09:41:21 -0400 Received: from mail.fireflyinternet.com ([109.228.58.192]:63430 "EHLO fireflyinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726948AbfHBNlV (ORCPT ); Fri, 2 Aug 2019 09:41:21 -0400 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 17818216-1500050 for multiple; Fri, 02 Aug 2019 14:41:17 +0100 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT To: Sergey Senozhatsky From: Chris Wilson In-Reply-To: <20190802133503.GA18318@tigerII.localdomain> Cc: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky References: <20190802123956.2450-1-sergey.senozhatsky@gmail.com> <20190802123956.2450-2-sergey.senozhatsky@gmail.com> <156475071634.6598.8668583907388398632@skylake-alporthouse-com> <156475141863.6598.6809215010139776043@skylake-alporthouse-com> <20190802131523.GB466@tigerII.localdomain> <20190802133503.GA18318@tigerII.localdomain> Message-ID: <156475327511.6598.417403815598052974@skylake-alporthouse-com> User-Agent: alot/0.6 Subject: Re: [PATCH 2/2] i915: do not leak module ref counter Date: Fri, 02 Aug 2019 14:41:15 +0100 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Sergey Senozhatsky (2019-08-02 14:35:03) > On (08/02/19 22:15), Sergey Senozhatsky wrote: > [..] > > > > Looking around, it looks like we always need to drop type after > > > > mounting. Should the > > > > put_filesystem(type); > > > > be here instead? > > > > > > > > Anyway, nice catch. > > > > > > Sigh. put_filesystem() is part of fs internals. I'd be tempted to add > > > > Good catch! > > > > So we can switch to vfs_kern_mount(), I guess, but pass different options, > > depending on has_transparent_hugepage(). > > Hmm. This doesn't look exactly right. It appears that vfs_kern_mount() > has a slightly different purpose. It's for drivers which register their > own fstype and fs_context/sb callbacks. A typical usage would be > > static struct file_system_type nfsd_fs_type = { > .owner→ → = THIS_MODULE, > .name→ → = "nfsd", > .init_fs_context = nfsd_init_fs_context, > .kill_sb→ = nfsd_umount, > }; > MODULE_ALIAS_FS("nfsd"); > > vfs_kern_mount(&nfsd_fs_type, SB_KERNMOUNT, "nfsd", NULL); > > i915 is a different beast, it just wants to mount fs and reconfigure > it, it doesn't want to be an fs. So it seems that current kern_mount() > is actually right. struct vfsmount *kern_mount(struct file_system_type *type) { struct vfsmount *mnt; mnt = vfs_kern_mount(type, SB_KERNMOUNT, type->name, NULL); if (!IS_ERR(mnt)) { /* * it is a longterm mount, don't release mnt until * we unmount before file sys is unregistered */ real_mount(mnt)->mnt_ns = MNT_NS_INTERNAL; } return mnt; } With the exception of fiddling with MNT_NS_INTERNAL, it seems amenable for our needs. -Chris