From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55412C433FE for ; Sun, 6 Mar 2022 23:25:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B40038D0002; Sun, 6 Mar 2022 18:25:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AEF2D8D0001; Sun, 6 Mar 2022 18:25:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98F5E8D0002; Sun, 6 Mar 2022 18:25:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 879DB8D0001 for ; Sun, 6 Mar 2022 18:25:01 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4A6BF61507 for ; Sun, 6 Mar 2022 23:25:01 +0000 (UTC) X-FDA: 79215544002.12.33A68AE Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf18.hostedemail.com (Postfix) with ESMTP id B5DEB1C0002 for ; Sun, 6 Mar 2022 23:25:00 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 0FBC5B80F91; Sun, 6 Mar 2022 23:24:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CA81C340EC; Sun, 6 Mar 2022 23:24:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1646609097; bh=0cqmIug9g7oG6mFioe4WoIPYjd14yu8jFI6WfYAYx2Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=mJm2xppEGzjgLE/glCcJmV0TehPtxjJ+lycqBJSyvAs8JzXqSIbKWj3rrVFiBbKL5 7/hnf52KDFrLBN3myrVg4WJ/9WFycZ2QECK8dsmsdk/BG2nBa12rv/S/E+SSIMEqou FiTgfJGetklkO9IgIBUfhvpyTJJKyOdhKYjQpqGQ= Date: Sun, 6 Mar 2022 15:24:56 -0800 From: Andrew Morton To: Jarkko Sakkinen Cc: Dave Hansen , Nathaniel McCallum , Reinette Chatre , linux-sgx@vger.kernel.org, jaharkes@cs.cmu.edu, linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, codalist@telemann.coda.cs.cmu.edu, linux-unionfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH RFC v2] mm: Add f_ops->populate() Message-Id: <20220306152456.2649b1c56da2a4ce4f487be4@linux-foundation.org> In-Reply-To: <20220306032655.97863-1-jarkko@kernel.org> References: <20220306032655.97863-1-jarkko@kernel.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: B5DEB1C0002 X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=mJm2xppE; dmarc=none; spf=pass (imf18.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Stat-Signature: 7tpj77wqf79tcpmx67xr5ysp96i1i11w X-HE-Tag: 1646609100-793987 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, 6 Mar 2022 05:26:55 +0200 Jarkko Sakkinen wrote: > Sometimes you might want to use MAP_POPULATE to ask a device driver to > initialize the device memory in some specific manner. SGX driver can use > this to request more memory by issuing ENCLS[EAUG] x86 opcode for each > page in the address range. Why is this useful? Please fully describe the benefit to kernel users. Convince us that the benefit justifies the code churn, maintenance cost and larger kernel footprint. Do we know of any other drivers which might use this? > Add f_ops->populate() with the same parameters as f_ops->mmap() and make > it conditionally called inside call_mmap(). Update call sites > accodingly. spello > -static inline int call_mmap(struct file *file, struct vm_area_struct *vma) > +static inline int call_mmap(struct file *file, struct vm_area_struct *vma, bool do_populate) > { > - return file->f_op->mmap(file, vma); > + int ret = file->f_op->mmap(file, vma); > + > + if (!ret && do_populate && file->f_op->populate) > + ret = file->f_op->populate(file, vma); > + > + return ret; > } Should this still be inlined?