kernel/ucount.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
From: MengEn Sun <mengensun@tencent.com>
Although kfree is a non-sleep function, it is possible to enter a
long chain of calls probabilistically, so it looks better to move
kfree from alloc_ucounts() out of the critical zone of ucounts_lock.
Reviewed-by: YueHong Wu <yuehongwu@tencent.com>
Signed-off-by: MengEn Sun <mengensun@tencent.com>
---
kernel/ucount.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/ucount.c b/kernel/ucount.c
index f950b5e5..86c5f1c 100644
--- a/kernel/ucount.c
+++ b/kernel/ucount.c
@@ -164,8 +164,8 @@ struct ucounts *get_ucounts(struct ucounts *ucounts)
struct ucounts *alloc_ucounts(struct user_namespace *ns, kuid_t uid)
{
struct hlist_head *hashent = ucounts_hashentry(ns, uid);
- struct ucounts *ucounts, *new;
bool wrapped;
+ struct ucounts *ucounts, *new = NULL;
spin_lock_irq(&ucounts_lock);
ucounts = find_ucounts(ns, uid, hashent);
@@ -182,17 +182,17 @@ struct ucounts *alloc_ucounts(struct user_namespace *ns, kuid_t uid)
spin_lock_irq(&ucounts_lock);
ucounts = find_ucounts(ns, uid, hashent);
- if (ucounts) {
- kfree(new);
- } else {
+ if (!ucounts) {
hlist_add_head(&new->node, hashent);
get_user_ns(new->ns);
spin_unlock_irq(&ucounts_lock);
return new;
}
}
+
wrapped = !get_ucounts_or_wrap(ucounts);
spin_unlock_irq(&ucounts_lock);
+ kfree(new);
if (wrapped) {
put_ucounts(ucounts);
return NULL;
--
1.8.3.1
Hi MengEn, On Fri, Dec 06, 2024 at 12:13:47PM +0800, mengensun88@gmail.com wrote: > From: MengEn Sun <mengensun@tencent.com> > > Although kfree is a non-sleep function, it is possible to enter a > long chain of calls probabilistically, so it looks better to move > kfree from alloc_ucounts() out of the critical zone of ucounts_lock. > > Reviewed-by: YueHong Wu <yuehongwu@tencent.com> > Signed-off-by: MengEn Sun <mengensun@tencent.com> > --- > kernel/ucount.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > It's a common convention to prefix your subject line with [PATCH] to let others know it's a patch. Additionally, when resending a patch without changes, consider adding RESEND to the subject line, e.g., [PATCH RESEND] ucounts: Move kfree() out of critical zone protected by ucounts_lock. See: https://www.kernel.org/doc/html/v6.12/process/submitting-patches.html#include-patch-in-the-subject Regards, Kuan-Wei
Hi Kuan Wei On Fri, 6 Dec 2024 13:55:51 +0800 visitorckw@gmail.com wrote: > Hi MengEn, > > On Fri, Dec 06, 2024 at 12:13:47PM +0800, mengensun88@gmail.com wrote: > > From: MengEn Sun <mengensun@tencent.com> > > > > Although kfree is a non-sleep function, it is possible to enter a > > long chain of calls probabilistically, so it looks better to move > > kfree from alloc_ucounts() out of the critical zone of ucounts_lock. > > > > Reviewed-by: YueHong Wu <yuehongwu@tencent.com> > > Signed-off-by: MengEn Sun <mengensun@tencent.com> > > --- > > kernel/ucount.c | 8 ++++---- > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > It's a common convention to prefix your subject line with [PATCH] to > let others know it's a patch. Additionally, when resending a patch > without changes, consider adding RESEND to the subject line, e.g., > [PATCH RESEND] ucounts: Move kfree() out of critical zone protected by > ucounts_lock. Thank you very much for your reply. I will make some changes here. > > See: https://www.kernel.org/doc/html/v6.12/process/submitting-patches.html#include-patch-in-the-subject I will study this document carefully. > > Regards, > Kuan-Wei Regards, Meng En
© 2016 - 2025 Red Hat, Inc.