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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3502C43217 for ; Sun, 6 Mar 2022 23:25:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233896AbiCFXZw (ORCPT ); Sun, 6 Mar 2022 18:25:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230331AbiCFXZv (ORCPT ); Sun, 6 Mar 2022 18:25:51 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C59793B3EE; Sun, 6 Mar 2022 15:24:58 -0800 (PST) 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 dfw.source.kernel.org (Postfix) with ESMTPS id 594D061052; Sun, 6 Mar 2022 23:24:58 +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 Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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?