From: Vladimir Kondratiev <vladimir.kondratiev@intel.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Marcelo Tosatti <marcelo@conectiva.com.br>
Subject: [PATCH] Re: Kernel threads resource leakage
Date: Sun, 17 Aug 2003 22:09:27 +0300 [thread overview]
Message-ID: <3F3FD2E7.9030808@intel.com> (raw)
I do not subscribed to the list, thus please in your reply CC me
(vladimir.kondratiev@intel.com)
Some time ago, I reported problem WRT resource leakage in kernel_thread.
(2.4.20) To demonstrate it, I submitted program that uses /proc file to
display some info and to start/stop kernel thread. I don't want to
re-post this code again.
Finally, I found that resource leak present only if you create
kernel_thread as non-root. With my previous example, do "insmod" as
root, while perform actual thread creation/destruction (echo "+"
>/proc/kthread etc.) as non-root.
To demonstrate it better, I added to /proc 'read' procedure content of
"struct user_struct" (current->user).
It makes clear, that in this case current->user->processes do not
decremented when thread destroyed, and eventually reaches user limit
(usually 4k processes). At this point, this user can do nothing.
Problem leaves in "reparent_to_init" code in kernel/sched.c; there
current->user is simply changed to point to INIT_USER without proper
resource management.
Does it worth inclusion in 2.4.22?
Following patch fixes this bug. I verified that with this patch applied,
kernel_thread behaves properly.
--- kernel/sched.c.orig 2003-08-17 20:12:14.000000000 +0300
+++ kernel/sched.c 2003-08-17 21:21:08.000000000 +0300
@@ -1274,8 +1274,16 @@
this_task->cap_permitted = CAP_FULL_SET;
this_task->keep_capabilities = 0;
memcpy(this_task->rlim, init_task.rlim, sizeof(*(this_task->rlim)));
- this_task->user = INIT_USER;
-
+ if (this_task->uid) { /* not root? switch user */
+ struct user_struct *old_user = this_task->user,
+ *new_user = INIT_USER;
+ this_task->uid = 0;
+ this_task->user = new_user;
+ atomic_inc(&new_user->__count);
+ atomic_inc(&new_user->processes);
+ atomic_dec(&old_user->processes);
+ free_uid(old_user);
+ }
spin_unlock(&runqueue_lock);
write_unlock_irq(&tasklist_lock);
}
reply other threads:[~2003-08-17 19:12 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=3F3FD2E7.9030808@intel.com \
--to=vladimir.kondratiev@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.