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
next prev parent 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