lkml.org 
[lkml]   [2000]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux-2.4.0-test7
On Wed, Aug 23, 2000 at 07:55:28PM -0700, Linus Torvalds wrote:
> test7:
> - pre7
> - get rid of unnecessary kernel lock in fork()

I wonder if this was a good idea. Look at these code pieces from
do_fork which are now executed without any lock held:


| retval = -EAGAIN;
| if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur)
| goto bad_fork_free;
| atomic_inc(&p->user->__count);
| atomic_inc(&p->user->processes);

This looks like an SMP race, that could allow a user to get more
processes than the number allowed by rlim. Mostly harmless, probably.

| /*
| * Counter increases are protected by
| * the kernel lock so nr_threads can't
| * increase under us (but it may decrease).
| */
| if (nr_threads >= max_threads)
| goto bad_fork_cleanup_count;

If this is really ok the comment should be removed and nr_threads
should better be atomic_t.

| p->pid = get_pid(clone_flags);

The pid returned by get_pid is not yet reserved, i.e. it won't be found
when get_pid searches the task list for used pids. Another call to get_pid
could theoretically return the same pid before the pid gets used here.
This is highly improbable, but if it actually happend it would probably
cause a big mess.

Are these races in fact impossible and I overlooked something or do
we take the risk because they either can't do to much harm or (like in
the last case) are too unlikely to happen?

best regards Christian

--
THAT'S ALL FOLKS!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.026 / U:5.656 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site