All of lore.kernel.org
 help / color / mirror / Atom feed
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.