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 C94FAC433EF for ; Thu, 30 Jun 2022 21:27:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4CAE98E0003; Thu, 30 Jun 2022 17:27:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 479068E0001; Thu, 30 Jun 2022 17:27:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F5268E0003; Thu, 30 Jun 2022 17:27:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 20C1E8E0001 for ; Thu, 30 Jun 2022 17:27:55 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E086B35619 for ; Thu, 30 Jun 2022 21:27:54 +0000 (UTC) X-FDA: 79636189668.05.017354F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf06.hostedemail.com (Postfix) with ESMTP id 64DD118003F for ; Thu, 30 Jun 2022 21:27:54 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 60C36623B5; Thu, 30 Jun 2022 21:27:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2B2B8C341C8; Thu, 30 Jun 2022 21:27:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1656624471; bh=NvqzBC09/Y80e2KCCsJMnIUOFz9YdwiZ8n8imT3Xf0M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mBnuqmNq9c697lusQeu8grTz767jz7CF7+OCqwXp0lfM27tk6sDfDWJff4BSEj+uV t+l/lxthKKe2CFd7EjDGBozodGo3nuc81zyI5CS/JfRJA7NERgu1YM1muQv1V00KCn DOSCx6LgT3MxQVCRsMvOsih4PkQPgPpjh8ruXHKpi2HF5nFCTbzTneuGT/W70dODmC 74s4jSk9sERp6B02J8gPVmpQ/WAGLgQ52gWGBdUSaigHZ8s7r9WJBX/YvkoluFwvSI GyLnkgod+yj9geRTSfXIeEWaT+1ULoU4Bsm/Nu7IDTyLljykR6Epph/gxiPwrTCpAH cOktWuenPSVQA== Date: Thu, 30 Jun 2022 14:27:50 -0700 From: "Darrick J. Wong" To: Khalid Aziz Cc: akpm@linux-foundation.org, willy@infradead.org, aneesh.kumar@linux.ibm.com, arnd@arndb.de, 21cnbao@gmail.com, corbet@lwn.net, dave.hansen@linux.intel.com, david@redhat.com, ebiederm@xmission.com, hagen@jauu.net, jack@suse.cz, keescook@chromium.org, kirill@shutemov.name, kucharsk@gmail.com, linkinjeon@kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, longpeng2@huawei.com, luto@kernel.org, markhemm@googlemail.com, pcc@google.com, rppt@kernel.org, sieberf@amazon.com, sjpark@amazon.de, surenb@google.com, tst@schoebel-theuer.de, yzaikin@google.com Subject: Re: [PATCH v2 4/9] mm/mshare: Add a read operation for msharefs files Message-ID: References: <05649b455e2191642e85cc5522ef39ad49fdeca3.1656531090.git.khalid.aziz@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05649b455e2191642e85cc5522ef39ad49fdeca3.1656531090.git.khalid.aziz@oracle.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656624474; a=rsa-sha256; cv=none; b=Rh4BS+5gPHdqTM4dyZCdAfHLkW34DV0CBCaEOFzCdJoZYQb6GEMqhiCq8fqlQoSsIPXnQN L0mztR3QatQUmDuvGtHCVmHW8Ev3TY5PibQB2ui19EK4buxHlJiHtIXrisNLRjCTt+As/h K70zY0OhYOhw5+xvKj3Wj/4kuNtwFO0= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=mBnuqmNq; spf=pass (imf06.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656624474; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xc1CAlCXn/nwDtsHexBWfNKS9qh05D3qa8UAnyu2ksM=; b=Udax5131UPtoUUJTwCAbaq+Sy+XzazoRhoVfJqvipzVsVq65VJrJJtb7QWj9IdWsSTEjJg 9FoTTS2ApXyQox5tsIVGFKlEY1bB3RZPBe2QWTkxxHEU9QNqKkcIWYtNms6oBvlNUuJvZv 6dbzHR4zbA9b5qLD28fHsq+RINX1n3M= X-Rspam-User: X-Rspamd-Server: rspam04 Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=mBnuqmNq; spf=pass (imf06.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: b4x785fmr9867n8ksuoxexhy16umnbmj X-Rspamd-Queue-Id: 64DD118003F X-HE-Tag: 1656624474-62959 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 Wed, Jun 29, 2022 at 04:53:55PM -0600, Khalid Aziz wrote: > When a new file is created under msharefs, allocate a new mm_struct > that will hold the VMAs for mshare region. Also allocate structure > to defines the mshare region and add a read operation to the file > that returns this information about the mshare region. Currently > this information is returned as a struct: > > struct mshare_info { > unsigned long start; > unsigned long size; > }; > > This gives the start address for mshare region and its size. > > Signed-off-by: Khalid Aziz > --- > include/uapi/linux/mman.h | 5 +++ > mm/mshare.c | 64 ++++++++++++++++++++++++++++++++++++++- > 2 files changed, 68 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/mman.h b/include/uapi/linux/mman.h > index f55bc680b5b0..56fe446e24b1 100644 > --- a/include/uapi/linux/mman.h > +++ b/include/uapi/linux/mman.h > @@ -41,4 +41,9 @@ > #define MAP_HUGE_2GB HUGETLB_FLAG_ENCODE_2GB > #define MAP_HUGE_16GB HUGETLB_FLAG_ENCODE_16GB > > +struct mshare_info { > + unsigned long start; > + unsigned long size; You might want to make these explicitly u64, since this is userspace ABI and you never know when someone will want to do something crazy like run 32-bit programs with mshare files. Also you might want to add some padding fields for flags, future expansion, etc. > +}; > + > #endif /* _UAPI_LINUX_MMAN_H */ > diff --git a/mm/mshare.c b/mm/mshare.c > index 2d5924d39221..d238b68b0576 100644 > --- a/mm/mshare.c > +++ b/mm/mshare.c > @@ -22,8 +22,14 @@ > #include > #include > #include > +#include > > static struct super_block *msharefs_sb; > +struct mshare_data { > + struct mm_struct *mm; > + refcount_t refcnt; > + struct mshare_info *minfo; > +}; > > static const struct inode_operations msharefs_dir_inode_ops; > static const struct inode_operations msharefs_file_inode_ops; > @@ -34,8 +40,29 @@ msharefs_open(struct inode *inode, struct file *file) > return simple_open(inode, file); > } > > +static ssize_t > +msharefs_read(struct kiocb *iocb, struct iov_iter *iov) > +{ > + struct mshare_data *info = iocb->ki_filp->private_data; > + size_t ret; > + struct mshare_info m_info; > + > + if (info->minfo != NULL) { > + m_info.start = info->minfo->start; > + m_info.size = info->minfo->size; > + } else { > + m_info.start = 0; > + m_info.size = 0; Hmmm, read()ing out the shared mapping information. Heh. When does this case happen? Is it before anybody mmaps this file into an address space? > + } > + ret = copy_to_iter(&m_info, sizeof(m_info), iov); > + if (!ret) > + return -EFAULT; > + return ret; > +} > + > static const struct file_operations msharefs_file_operations = { > .open = msharefs_open, > + .read_iter = msharefs_read, > .llseek = no_llseek, > }; > > @@ -73,12 +100,43 @@ static struct dentry > return ERR_PTR(-ENOMEM); > } > > +static int > +msharefs_fill_mm(struct inode *inode) > +{ > + struct mm_struct *mm; > + struct mshare_data *info = NULL; > + int retval = 0; > + > + mm = mm_alloc(); > + if (!mm) { > + retval = -ENOMEM; > + goto err_free; > + } > + > + info = kzalloc(sizeof(*info), GFP_KERNEL); > + if (!info) { > + retval = -ENOMEM; > + goto err_free; > + } > + info->mm = mm; > + info->minfo = NULL; > + refcount_set(&info->refcnt, 1); > + inode->i_private = info; > + > + return 0; > + > +err_free: > + if (mm) > + mmput(mm); > + kfree(info); > + return retval; > +} > + > static struct inode > *msharefs_get_inode(struct super_block *sb, const struct inode *dir, > umode_t mode) > { > struct inode *inode = new_inode(sb); > - > if (inode) { > inode->i_ino = get_next_ino(); > inode_init_owner(&init_user_ns, inode, dir, mode); > @@ -89,6 +147,10 @@ static struct inode > case S_IFREG: > inode->i_op = &msharefs_file_inode_ops; > inode->i_fop = &msharefs_file_operations; > + if (msharefs_fill_mm(inode) != 0) { > + discard_new_inode(inode); > + inode = ERR_PTR(-ENOMEM); Is it intentional to clobber the msharefs_fill_mm return value and replace it with ENOMEM? --D > + } > break; > case S_IFDIR: > inode->i_op = &msharefs_dir_inode_ops; > -- > 2.32.0 >