From: Cai Xinchen <caixinchen1@huawei.com>
To: <viro@zeniv.linux.org.uk>, <brauner@kernel.org>, <jack@suse.cz>,
<miklos@szeredi.hu>, <amir73il@gmail.com>, <paul@paul-moore.com>,
<jmorris@namei.org>, <serge@hallyn.com>,
<stephen.smalley.work@gmail.com>, <omosnace@redhat.com>,
<gregkh@linuxfoundation.org>, <sashal@kernel.org>,
<bboscaccy@linux.microsoft.com>, <caixinchen1@huawei.com>
Cc: <linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-unionfs@vger.kernel.org>,
<linux-security-module@vger.kernel.org>,
<selinux@vger.kernel.org>, <bpf@vger.kernel.org>,
<stable@vger.kernel.org>, <lujialin4@huawei.com>
Subject: [PATCH stable/linux-5.10.y 2/7] fs: move kmem_cache_zalloc() into alloc_empty_file*() helpers
Date: Mon, 29 Jun 2026 15:06:48 +0800 [thread overview]
Message-ID: <20260629070653.580879-3-caixinchen1@huawei.com> (raw)
In-Reply-To: <20260629070653.580879-1-caixinchen1@huawei.com>
From: Amir Goldstein <amir73il@gmail.com>
[ Upstream commit 8a05a8c31d06c5d0d67b273a4a00f87269adde82 ]
Use a common helper init_file() instead of __alloc_file() for
alloc_empty_file*() helpers and improrve the documentation.
This is needed for a follow up patch that allocates a backing_file
container.
Suggested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Message-Id: <20230615112229.2143178-4-amir73il@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Cai Xinchen <caixinchen1@huawei.com>
---
fs/file_table.c | 41 ++++++++++++++++++++++++++---------------
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/fs/file_table.c b/fs/file_table.c
index 7a3b4a7f6808..be24d724b407 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -93,20 +93,15 @@ int proc_nr_files(struct ctl_table *table, int write,
}
#endif
-static struct file *__alloc_file(int flags, const struct cred *cred)
+static int init_file(struct file *f, int flags, const struct cred *cred)
{
- struct file *f;
int error;
- f = kmem_cache_zalloc(filp_cachep, GFP_KERNEL);
- if (unlikely(!f))
- return ERR_PTR(-ENOMEM);
-
f->f_cred = get_cred(cred);
error = security_file_alloc(f);
if (unlikely(error)) {
file_free_rcu(&f->f_u.fu_rcuhead);
- return ERR_PTR(error);
+ return error;
}
atomic_long_set(&f->f_count, 1);
@@ -118,7 +113,7 @@ static struct file *__alloc_file(int flags, const struct cred *cred)
f->f_mode = OPEN_FMODE(flags);
/* f->f_version: 0 */
- return f;
+ return 0;
}
/* Find an unused file structure and return a pointer to it.
@@ -135,6 +130,7 @@ struct file *alloc_empty_file(int flags, const struct cred *cred)
{
static long old_max;
struct file *f;
+ int error;
/*
* Privileged users can go above max_files
@@ -148,9 +144,15 @@ struct file *alloc_empty_file(int flags, const struct cred *cred)
goto over;
}
- f = __alloc_file(flags, cred);
- if (!IS_ERR(f))
- percpu_counter_inc(&nr_files);
+ f = kmem_cache_zalloc(filp_cachep, GFP_KERNEL);
+ if (unlikely(!f))
+ return ERR_PTR(-ENOMEM);
+
+ error = init_file(f, flags, cred);
+ if (unlikely(error))
+ return ERR_PTR(error);
+
+ percpu_counter_inc(&nr_files);
return f;
@@ -166,14 +168,23 @@ struct file *alloc_empty_file(int flags, const struct cred *cred)
/*
* Variant of alloc_empty_file() that doesn't check and modify nr_files.
*
- * Should not be used unless there's a very good reason to do so.
+ * This is only for kernel internal use, and the allocate file must not be
+ * installed into file tables or such.
*/
struct file *alloc_empty_file_noaccount(int flags, const struct cred *cred)
{
- struct file *f = __alloc_file(flags, cred);
+ struct file *f;
+ int error;
+
+ f = kmem_cache_zalloc(filp_cachep, GFP_KERNEL);
+ if (unlikely(!f))
+ return ERR_PTR(-ENOMEM);
+
+ error = init_file(f, flags, cred);
+ if (unlikely(error))
+ return ERR_PTR(error);
- if (!IS_ERR(f))
- f->f_mode |= FMODE_NOACCOUNT;
+ f->f_mode |= FMODE_NOACCOUNT;
return f;
}
--
2.18.0.huawei.25
next prev parent reply other threads:[~2026-06-29 6:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 7:06 [PATCH stable/linux-5.10.y 0/7] Backport Fix incorrect overlayfs mmap() and mprotect() LSM access controls Cai Xinchen
2026-06-29 7:06 ` [PATCH stable/linux-5.10.y 1/7] ovl: pass layer mnt to ovl_open_realfile() Cai Xinchen
2026-06-29 7:06 ` Cai Xinchen [this message]
2026-06-29 7:06 ` [PATCH stable/linux-5.10.y 3/7] fs: use backing_file container for internal files with "fake" f_path Cai Xinchen
2026-06-29 7:06 ` [PATCH stable/linux-5.10.y 4/7] lsm: constify the 'file' parameter in security_binder_transfer_file() Cai Xinchen
2026-06-29 7:06 ` [PATCH stable/linux-5.10.y 5/7] fs: prepare for adding LSM blob to backing_file Cai Xinchen
2026-06-29 7:06 ` [PATCH stable/linux-5.10.y 6/7] lsm: add backing_file LSM hooks Cai Xinchen
2026-06-29 7:06 ` [PATCH stable/linux-5.10.y 7/7] selinux: fix overlayfs mmap() and mprotect() access checks Cai Xinchen
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=20260629070653.580879-3-caixinchen1@huawei.com \
--to=caixinchen1@huawei.com \
--cc=amir73il@gmail.com \
--cc=bboscaccy@linux.microsoft.com \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=jmorris@namei.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=lujialin4@huawei.com \
--cc=miklos@szeredi.hu \
--cc=omosnace@redhat.com \
--cc=paul@paul-moore.com \
--cc=sashal@kernel.org \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=stable@vger.kernel.org \
--cc=stephen.smalley.work@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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