linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Prakash Sangappa <prakash.sangappa@oracle.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: muchun.song@linux.dev, akpm@linux-foundation.org,
	willy@infradead.org, prakash.sangappa@oracle.com
Subject: [RFC PATCH 1/1] hugetlbfs: Add mount option to choose normal mmap behavior
Date: Thu,  2 May 2024 18:21:10 -0700	[thread overview]
Message-ID: <1714699270-7360-2-git-send-email-prakash.sangappa@oracle.com> (raw)
In-Reply-To: <1714699270-7360-1-git-send-email-prakash.sangappa@oracle.com>

Currently hugetlbfs file size gets extended in a PROT_WRITE mmap call,
if mmap size exceeds the file size. This is not normal filesystem behavior.

Some applications expect normal file system behavior for mmap, such that
the process would receive a signal when accessing mapped address beyond
file size. This will not happen if the file size gets extended by mmap(2).

Changing current behavior for hugetlbfs can potentially break existing
applications. Therefore provide a mount option "nommapfilesz" to choose
normal mmap behavior.

Suggested-by: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Prakash Sangappa <prakash.sangappa@oracle.com>
---
 fs/hugetlbfs/inode.c    | 19 ++++++++++++++++++-
 include/linux/hugetlb.h |  1 +
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 6502c7e..e37867a 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -58,6 +58,7 @@ struct hugetlbfs_fs_context {
 	kuid_t			uid;
 	kgid_t			gid;
 	umode_t			mode;
+	ushort			nommapfilesz;
 };
 
 int sysctl_hugetlb_shm_group;
@@ -70,6 +71,7 @@ enum hugetlb_param {
 	Opt_pagesize,
 	Opt_size,
 	Opt_uid,
+	Opt_nommapfilesz,
 };
 
 static const struct fs_parameter_spec hugetlb_fs_parameters[] = {
@@ -80,6 +82,7 @@ static const struct fs_parameter_spec hugetlb_fs_parameters[] = {
 	fsparam_string("pagesize",	Opt_pagesize),
 	fsparam_string("size",		Opt_size),
 	fsparam_u32   ("uid",		Opt_uid),
+	fsparam_flag  ("nommapfilesz",  Opt_nommapfilesz),
 	{}
 };
 
@@ -159,7 +162,12 @@ static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma)
 		goto out;
 
 	ret = 0;
-	if (vma->vm_flags & VM_WRITE && inode->i_size < len)
+	/*
+	 * If filesystem is mounted with 'nommapfilesz' option, then
+	 * don't update file size.
+	 */
+	if (!(HUGETLBFS_SB(inode->i_sb)->nommapfilesz)
+			&& vma->vm_flags & VM_WRITE && inode->i_size < len)
 		i_size_write(inode, len);
 out:
 	inode_unlock(inode);
@@ -1169,6 +1177,8 @@ static int hugetlbfs_show_options(struct seq_file *m, struct dentry *root)
 		seq_printf(m, ",mode=%o", sbinfo->mode);
 	if (sbinfo->max_inodes != -1)
 		seq_printf(m, ",nr_inodes=%lu", sbinfo->max_inodes);
+	if (sbinfo->nommapfilesz)
+		seq_puts(m, ",nommapfilesz");
 
 	hpage_size /= 1024;
 	mod = 'K';
@@ -1430,6 +1440,11 @@ static int hugetlbfs_parse_param(struct fs_context *fc, struct fs_parameter *par
 			ctx->min_val_type = SIZE_PERCENT;
 		return 0;
 
+	case Opt_nommapfilesz:
+		/* don't update file size in mmap call */
+		ctx->nommapfilesz = 1;
+		return 0;
+
 	default:
 		return -EINVAL;
 	}
@@ -1487,6 +1502,7 @@ hugetlbfs_fill_super(struct super_block *sb, struct fs_context *fc)
 	sbinfo->uid		= ctx->uid;
 	sbinfo->gid		= ctx->gid;
 	sbinfo->mode		= ctx->mode;
+	sbinfo->nommapfilesz    = ctx->nommapfilesz;
 
 	/*
 	 * Allocate and initialize subpool if maximum or minimum size is
@@ -1558,6 +1574,7 @@ static int hugetlbfs_init_fs_context(struct fs_context *fc)
 	ctx->min_hpages	= -1; /* No default minimum size */
 	ctx->max_val_type = NO_SIZE;
 	ctx->min_val_type = NO_SIZE;
+	ctx->nommapfilesz = 0; /* allows file size update in mmap call */
 	fc->fs_private = ctx;
 	fc->ops	= &hugetlbfs_fs_context_ops;
 	return 0;
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 77b30a8..282cab5 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -537,6 +537,7 @@ struct hugetlbfs_sb_info {
 	kuid_t	uid;
 	kgid_t	gid;
 	umode_t mode;
+	ushort	nommapfilesz;
 };
 
 static inline struct hugetlbfs_sb_info *HUGETLBFS_SB(struct super_block *sb)
-- 
2.7.4



  reply	other threads:[~2024-05-03  1:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-03  1:21 [RFC PATCH 0/1] Address hugetlbfs " Prakash Sangappa
2024-05-03  1:21 ` Prakash Sangappa [this message]
2024-05-07 12:00 ` David Hildenbrand
2024-05-08 17:00   ` Prakash Sangappa
2024-05-08 17:28     ` David Hildenbrand
2024-05-10 16:28       ` Prakash Sangappa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1714699270-7360-2-git-send-email-prakash.sangappa@oracle.com \
    --to=prakash.sangappa@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=muchun.song@linux.dev \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox