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 88631CCA473 for ; Thu, 30 Jun 2022 21:50:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E96798E0002; Thu, 30 Jun 2022 17:50:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E1F388E0001; Thu, 30 Jun 2022 17:50:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBFCC8E0002; Thu, 30 Jun 2022 17:50:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id B92388E0001 for ; Thu, 30 Jun 2022 17:50:20 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8D8D3205A4 for ; Thu, 30 Jun 2022 21:50:20 +0000 (UTC) X-FDA: 79636246200.28.596832D Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf07.hostedemail.com (Postfix) with ESMTP id E206040043 for ; Thu, 30 Jun 2022 21:50:19 +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 34154B82D3D; Thu, 30 Jun 2022 21:50:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2E89C34115; Thu, 30 Jun 2022 21:50:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1656625817; bh=wfSJGrMKqxvbLYGQU0nsffNjn4KCaA4buDdhPQhY4To=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GPhm8uZPGces1RaLtCvMMal0vcmz7t6lR/r2s9/1IMzG3MIwvr7913wKO1JO1MuID Nt57MbT4Jgf6ZcoEeOjnqRrCSVNJLAl1EOffpfBw5Z+yQSAD/VcbAwXr1OKlucX5Vw yKMyKCjF07kdXOEswr6FXnCXAeGQ6lNcXc2NBu8m2/CLYXY1LEuh5zFzO8rwmE8b5Q Zcgj1JucApy7H7ux4Yj724RHb+fjOBUR6rS2yqG3YxAaafj+qXERMji6I9Pub0OAeq G6Nwd5qybMnEfzmhr4ImxffUDjQ5QDJlzEU7TvkVeZrGLLvZDwWR4BxAKTts+1qBCM uLfdZKFwPB8bg== Date: Thu, 30 Jun 2022 14:50:16 -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 7/9] mm/mshare: Add unlink and munmap support Message-ID: References: <1b0a0e8c9558766f13a64ae93092eb8c9ea7965d.1656531090.git.khalid.aziz@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1b0a0e8c9558766f13a64ae93092eb8c9ea7965d.1656531090.git.khalid.aziz@oracle.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656625820; a=rsa-sha256; cv=none; b=KsmCBeohMUED76TocS4RtDsVIdVdxKeM5prfRpsaLRYhoy2WQeFkFElbFRdOsSB/UQPbZN NOnMJCW0E4UZNco0AxeS7vaY3OHTHpmXj02glNNSSKxvwo9eQC8bntYgsmVXYg1P9xjpYj Ru/YSv1C9EkmnW5ymskMGvibir07Tv0= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GPhm8uZP; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf07.hostedemail.com: domain of djwong@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=djwong@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656625820; 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=7k0G84iGlTCTsJ8e0wTHRwTi82ejjKGxaCwFirTENF4=; b=8dCsAO3aj8ktmkyT9wNH9nDghubTxl8xGCIqR6G09gYHIOCZWdfdAkOfkuc4sdJIPKgzLg uj0YJUU0uT2tv8f7u8R47rYu1HTKomF+7dzXk+OtFXMoDk3ymbZ7VwZSGEkbp8IlDpUo5t P0kr09XxKJ+vD71rd/c6qXtLz+rqnQY= Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GPhm8uZP; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf07.hostedemail.com: domain of djwong@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=djwong@kernel.org X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: E206040043 X-Stat-Signature: imdamjakwua8b4myb67eo1gofthxycw9 X-Rspam-User: X-HE-Tag: 1656625819-411122 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:58PM -0600, Khalid Aziz wrote: > Number of mappings of an mshare region should be tracked so it can > be removed when there are no more references to it and associated > file has been deleted. This add code to support the unlink operation > for associated file, remove the mshare region on file deletion if > refcount goes to zero, add munmap operation to maintain refcount > to mshare region and remove it on last munmap if file has been > deleted. > > Signed-off-by: Khalid Aziz > --- > mm/mshare.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 63 insertions(+), 1 deletion(-) > > diff --git a/mm/mshare.c b/mm/mshare.c > index 088a6cab1e93..90ce0564a138 100644 > --- a/mm/mshare.c > +++ b/mm/mshare.c > @@ -29,6 +29,7 @@ static struct super_block *msharefs_sb; > struct mshare_data { > struct mm_struct *mm; > refcount_t refcnt; > + int deleted; > struct mshare_info *minfo; > }; > > @@ -48,6 +49,7 @@ msharefs_read(struct kiocb *iocb, struct iov_iter *iov) > size_t ret; > struct mshare_info m_info; > > + mmap_read_lock(info->mm); > if (info->minfo != NULL) { > m_info.start = info->minfo->start; > m_info.size = info->minfo->size; > @@ -55,18 +57,42 @@ msharefs_read(struct kiocb *iocb, struct iov_iter *iov) > m_info.start = 0; > m_info.size = 0; > } > + mmap_read_unlock(info->mm); > ret = copy_to_iter(&m_info, sizeof(m_info), iov); > if (!ret) > return -EFAULT; > return ret; > } > > +static void > +msharefs_close(struct vm_area_struct *vma) > +{ > + struct mshare_data *info = vma->vm_private_data; > + > + if (refcount_dec_and_test(&info->refcnt)) { > + mmap_read_lock(info->mm); > + if (info->deleted) { > + mmap_read_unlock(info->mm); > + mmput(info->mm); > + kfree(info->minfo); > + kfree(info); Aren't filesystems supposed to take care of disposing of the file data in destroy_inode? IIRC struct inode doesn't go away until all fds are closed, mappings are torn down, and there are no more references from dentries. I could be misremembering since it's been a few months since I went looking at the (VFS) inode lifecycle. > + } else { > + mmap_read_unlock(info->mm); > + } > + } > +} > + > +static const struct vm_operations_struct msharefs_vm_ops = { > + .close = msharefs_close, > +}; > + > static int > msharefs_mmap(struct file *file, struct vm_area_struct *vma) > { > struct mshare_data *info = file->private_data; > struct mm_struct *mm = info->mm; > > + mmap_write_lock(mm); > /* > * If this mshare region has been set up once already, bail out > */ > @@ -80,10 +106,14 @@ msharefs_mmap(struct file *file, struct vm_area_struct *vma) > mm->task_size = vma->vm_end - vma->vm_start; > if (!mm->task_size) > mm->task_size--; > + mmap_write_unlock(mm); > info->minfo->start = mm->mmap_base; > info->minfo->size = mm->task_size; > + info->deleted = 0; > + refcount_inc(&info->refcnt); > vma->vm_flags |= VM_SHARED_PT; > vma->vm_private_data = info; > + vma->vm_ops = &msharefs_vm_ops; > return 0; > } > > @@ -240,6 +270,38 @@ msharefs_mkdir(struct user_namespace *mnt_userns, struct inode *dir, > return ret; > } > > +static int > +msharefs_unlink(struct inode *dir, struct dentry *dentry) > +{ > + struct inode *inode = d_inode(dentry); > + struct mshare_data *info = inode->i_private; > + > + /* > + * Unmap the mshare region if it is still mapped in > + */ > + vm_munmap(info->minfo->start, info->minfo->size); > + > + /* > + * Mark msharefs file for deletion so it can not be opened > + * and used for mshare mappings any more > + */ > + simple_unlink(dir, dentry); > + mmap_write_lock(info->mm); > + info->deleted = 1; > + mmap_write_unlock(info->mm); What if the file is hardlinked? --D > + > + /* > + * Is this the last reference? If so, delete mshare region and > + * remove the file > + */ > + if (!refcount_dec_and_test(&info->refcnt)) { > + mmput(info->mm); > + kfree(info->minfo); > + kfree(info); > + } > + return 0; > +} > + > static const struct inode_operations msharefs_file_inode_ops = { > .setattr = simple_setattr, > .getattr = simple_getattr, > @@ -248,7 +310,7 @@ static const struct inode_operations msharefs_dir_inode_ops = { > .create = msharefs_create, > .lookup = simple_lookup, > .link = simple_link, > - .unlink = simple_unlink, > + .unlink = msharefs_unlink, > .mkdir = msharefs_mkdir, > .rmdir = simple_rmdir, > .mknod = msharefs_mknod, > -- > 2.32.0 >